From p2psip-bounces@ietf.org Sat Dec 01 00:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyKZu-0006YX-NA; Sat, 01 Dec 2007 00:07:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyKZs-0006YM-IT for p2psip@ietf.org; Sat, 01 Dec 2007 00:07:44 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyKZr-0004rD-UK for p2psip@ietf.org; Sat, 01 Dec 2007 00:07:44 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2019529rvb for ; Fri, 30 Nov 2007 21:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=PlG30DwVYzLQQBIBsar0Bb6ayTRunE7sa/cM6k6LVGY=; b=xCN6hAnOKOxSip9il17GvYpX+E8CdWXMi6NH86jIZzi2Ectv+ddfKuOJSyVLC1PsIOD5+RGLiVxo5Hw1ScxEgHp8or5UVDTg3WydJH8KZu01c+DsBj/T573QAvLSxUf3uG+mkq3XUlFeD/K+A2G6C0MprJKztoH3XVya8uF3LkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QUer9JKRi19k9NjwL+Hu9fnYVrR721J4gIPIiDlrpK9VGCc+WWSMJmdK+JY5nWJMKBBYwBVzT8Q2INylECyZRQcEXOWXgoVhv9FprvzxoUHRmvrdTzY9Hp2Zvw63TwKKo0bz48ZWU9alR3zWpWqbKP7OYQXoCnKjQgL7X/Fb3+U= Received: by 10.141.19.16 with SMTP id w16mr4447552rvi.1196485662518; Fri, 30 Nov 2007 21:07:42 -0800 (PST) Received: by 10.141.40.5 with HTTP; Fri, 30 Nov 2007 21:07:42 -0800 (PST) Message-ID: <7b683f3f0711302107g5ac95623gdc0d601af579c094@mail.gmail.com> Date: Sat, 1 Dec 2007 00:07:42 -0500 From: "Eunsoo Shim" To: "Dean Willis" Subject: Re: [P2PSIP] Client discussion in Vancouver In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The fundamental difference between Peer and Client? Peers do something (overlay maintenance and routing) Clients do not it. That's why the slides use the analogy of saying Peers are 'routing' nodes and Clients are 'non-routing' nodes. Don't look for what Peers do differently from Clients. Look for what Peers do that Clients do not. Thanks. Eunsoo On Nov 30, 2007 9:29 PM, Dean Willis wrote: > > On Nov 30, 2007, at 7:21 PM, > > wrote: > > > > > Hi all, > > > > Please see a draft version of the presentation about clients. Any > > comments appreciated! > > http://netlabathut.googlepages.com/Clients_02.ppt > > > > This still doesn't say a lot about what peers really do differently > from clients. Perhaps it would be better expressed as a set of use > cases? > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 01 07:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyR9F-0006Ks-Gk; Sat, 01 Dec 2007 07:08:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyR9E-0006Kd-H7 for p2psip@ietf.org; Sat, 01 Dec 2007 07:08:40 -0500 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyR9E-0005AC-57 for p2psip@ietf.org; Sat, 01 Dec 2007 07:08:40 -0500 Received: by wa-out-1112.google.com with SMTP id k40so4890474wah for ; Sat, 01 Dec 2007 04:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=J5faMr+ps6N/giMiqPYt/QxiC+l6RLWvUAumrweLzL8=; b=IrMW9O5H+ZaKki2SqFlbAApgUDIwtsr/T22Sl/ydRBPgEFSafCzjkZT9ge0muAxFR3mlY8DJFiJiZ9QpQI6ehfHp+yVlt/ZGqRgZlRjppmrMlKTT9WExl24K1iM/dUqP6TzBB0dTPvuP/pv9uNNO13/SGYRBkm+vzETC+MPeRfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=vr3eY+gCgDrBZTV2slzqTMXft0fcMnStwMkseDJxLl3KvgFBD+gAvYBVZY/28S/sFIQuFr9iEAayRhnooJGd+kO1twkyBeioq5URkaZ3I7kFRUreRbP1QzZlNAKfjcW5MAucDb9zusNkZb8Q3wVQsDWqOs7UAl494DhX7nc++2c= Received: by 10.142.135.9 with SMTP id i9mr549246wfd.1196510919545; Sat, 01 Dec 2007 04:08:39 -0800 (PST) Received: by 10.142.132.18 with HTTP; Sat, 1 Dec 2007 04:08:39 -0800 (PST) Message-ID: <20d2bdfb0712010408n23947222m26c8a2256a3b7f81@mail.gmail.com> Date: Sat, 1 Dec 2007 07:08:39 -0500 From: "Bruce Lowekamp" To: "Dean Willis" Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing In-Reply-To: <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> <47509618.7060001@cisco.com> <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> X-Google-Sender-Auth: 5110dc130762cc45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean, On Nov 30, 2007 9:27 PM, Dean Willis wrote: > These are the kinds of things that can happen when we start thinking > of the overlay as a distributed database, not just as a distributed > proxy-registrar. I was with you until I got to this last paragraph. What I was thinking is that some of the current proposals (I will speak only for reload since it's the one I'm most familiar with) offer the ability to implement any of these scenarios you propose, but don't describe how it would be accomplished. If we're going to be writing drafts that describe fairly generic distributed databases, I think we need to spend more time writing how to implement interesting sip functionality on top of those systems. I think at the heart of your email is that we're not doing that right now. Take reload. It offers get/put with usage-defined types and security. It supports tunneling application data over the overlay as well as serving as an intermediary for ICE negotiation and TURN server location. These are basic tools that I think are capable of implementing any of the scenarios you propose. I haven't thought much about "how would you locate generic routers using reload" separate from managing overlay routing, but once you have that routing vector, all you need is a storage format for it. For the generic proxy support, the user has to locate a proxy willing to provide this service. We can define as part of the usage that all peers must provide this service, or we can allow the UA to select the proxy it wishes to use. I can think of use cases for both scenarios. Time for my flight, but I think the important point is that we need to start working out more application details of how these will work within the proposed frameworks. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 01 09:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyTV1-0003ea-Fv; Sat, 01 Dec 2007 09:39:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyTV0-0003ZB-OW for p2psip@ietf.org; Sat, 01 Dec 2007 09:39:18 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyTV0-0004PA-6f for p2psip@ietf.org; Sat, 01 Dec 2007 09:39:18 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sat, 01 Dec 2007 06:39:14 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB1EdChb023320; Sat, 1 Dec 2007 06:39:13 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB1Ed1RE001540; Sat, 1 Dec 2007 06:39:11 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 06:39:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Client discussion in Vancouver Date: Sat, 1 Dec 2007 06:39:01 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE373@namail5.corp.adobe.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Client discussion in Vancouver Thread-Index: AcgzuHuQE+bcMuT1QNyK9HOLLqxPpAAbCGgg References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 01 Dec 2007 14:39:02.0162 (UTC) FILETIME=[EA6FBF20:01C83427] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1444429392==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1444429392== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83427.EA144ACF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83427.EA144ACF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I suggest edits for two items: =20 * A device should become a peer whenever possible =20 This is not always possible or desirable in certain usage scenarios =20 * Resource limitations + churn/intermittent connectivity make a poor peer =20 Replace "poor " with "undesirable", since the churn on the overlay outweighs the benefit of having this peer.=20 This is the reason why small mobile devices may be undesirable peers. Some analytical work with numbers would be helpful here. =20 Henry =20 ________________________________ From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] Sent: Friday, November 30, 2007 7:21 PM To: p2psip@ietf.org Subject: [P2PSIP] Client discussion in Vancouver =20 =20 Hi all,=20 Please see a draft version of the presentation about clients. Any comments appreciated!=20 http://netlabathut.googlepages.com/Clients_02.ppt =20 Marcin=20 ------_=_NextPart_001_01C83427.EA144ACF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Client discussion in Vancouver

I suggest edits for two = items:

 

  • A device should become a peer whenever = possible

 

This is not always possible or = desirable in certain usage scenarios

 

  • Resource limitations + churn/intermittent connectivity make a poor = peer

 

Replace “poor “ with = “undesirable”, since the churn on the overlay outweighs the benefit of having this = peer.

This is the reason why small mobile devices may be undesirable peers. Some analytical work with numbers = would be helpful here.

 

Henry

 

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Friday, November = 30, 2007 7:21 PM
To: = p2psip@ietf.org
Subject: [P2PSIP] Client discussion in Vancouver

=

 

 

Hi all,

Please see a draft version of the presentation about clients. Any comments appreciated!
http://netlabathut.googlepag= es.com/Clients_02.ppt

Marcin

------_=_NextPart_001_01C83427.EA144ACF-- --===============1444429392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1444429392==-- From p2psip-bounces@ietf.org Sat Dec 01 14:01:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXaw-0006Z1-8X; Sat, 01 Dec 2007 14:01:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXau-0006Qz-Sa for p2psip@ietf.org; Sat, 01 Dec 2007 14:01:40 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyXau-0002Ob-0k for p2psip@ietf.org; Sat, 01 Dec 2007 14:01:40 -0500 X-AuditID: c0a8013c-acf21bb000001e2e-70-4751af8e294b Received: from s73602 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 59F134DC009 for ; Sat, 1 Dec 2007 12:01:34 -0700 (MST) Message-ID: <1eaf01c8344c$8d2721d0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "P2PSIP Mailing List" References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com><47509618.7060001@cisco.com> <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Sat, 1 Dec 2007 11:01:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean, I'm following up to this e-mail, but thanks for sending the first one, too. It's very helpful, and goes to the core of the routing discussion. I'll try to assimilate it as part of my slides (he said on Saturday :-). We still haven't talked about use cases/application scenarios for a while now, and until we have that conversation, people who are assuming that mid-point policy enforcement will happen will not understand people who assume that mid-point policy enforcement won't happen, or even that it's not possible. ... and this isn't even an attribute in the current application scenarios draft. My bad. Maybe it could be, by the end of the week. I don't see how to move forward here as long as proposals don't have to solve the same problem. Picking a direction by voting ("consensing"?) proposals off the island isn't likely to be optimal. Thanks, Spencer > On Nov 30, 2007, at 5:00 PM, Paul Kyzivat wrote: > >> Dean, >> >> Very interesting stuff you wrote below. > > Thanks. I think "interesting" is a good adjective. Far more polite than > "deranged", which probably came to mind for at least a few readers. > >> >> A related question: >> >> in a regular sip network, UAs often "hide behind" a proxy - the proxy >> acts as a screening device. It also acts as a policy agent for selecting >> which of possibly several UAs for the AOR gets a call. (It may also do >> callerprefs but typically callee policy takes precedence.) >> >> Is any of this behavior in scope for P2PSIP? Is it part of the finding >> function, the routing function, or some new function? >> > > I've been pondering that question for some time. > > Either we lose much of the functionality built into SIP proxies (which > includes what you list above along with, to my mind, the far more > important function of hiding the UA's IP address unless proxy policy lets > the request through), or we have to find a new way to provide those > functions. > > I think this could take two forms, one novel, one conventional. > > In the conventional approach, the "peer" that would be found using a > "get" on a AOR resource is a SIP proxy, and once it gets a SIP request, > it applies the usual policy decisions before passing the request on to > the end UA. This "passing on" could be done using conventional SIP, or it > could be done using the overlay. What makes it work is the same sort of > indirection that maps AOR to Contact to User. We'd just introduce an > intermediary resource ID. In effect, Alice might insert her two phones > "alice-1@example.com" and "alice-2@example.com" into the overlay, and her > proxy peer might insert "alice@example.com" and be configured with a > policy table that applies "contact routing" towards the phones. We can > even think of using a SIP REGISTER request, routed over the overlay, to > inform the proxy peer about the downstream bindings. Perhaps there is > even a way to apply CPL in this sort of model. > > A more novel approach would be to put the traditional "proxy policy" > functions into the overlay. One approach would be to have a "policy > language", and for each AOR, put a policy resource into the overlay. > Before sending a message, a peer would first do a "get" on the policy > resource, then interpret the policy resource before dispatching the > request. For example, the policy resource for "alice@example.com" might > indicate that she's busy next week and all calls should be retargeted to > "alice@voicemail.example.com". Alice's various devices (assuming she has > more than one) might achieve the effect of SIP contact-registration by > amending Alice's policy resource to add themselves to the policy. > > > I think the current models rather naively assume "one AOR, one device" > and that any policy enforcement can be done in the terminating device. > There's probably an underlying assumption that any more complex policy > gets handled by something analogous to a B2BUA, but I don't think it > really has to work that way. Indeed, I expect to see all sorts of > policy-driven indirection models working their way into the overlay once > we get the basic functions sorted out. But that does raise the question > of the system being more effective if we build these functions in up > front. > > Here's a nifty use case: Let's say Alice only wants Bob and Charlie to be > able to deduce her location from the overlay. The resource > "alice@example.com" might, instead of returning a Contact, instead return > only a policy object. That policy object might contain sections encrypted > with Bob and Charlie's public keys. Each section, when decrypted, would > provide a retargeting to an anonymous resource ID that Alice minted for > temporary use. Bob "calls" alice, "getting" the resource record > "alice@example.com", finds it to be a policy object that has a section > keyed for him, decrypts it, finds that it contains instructions to > retarget to another resource, does a "connect" on that resource, and is > connected to Alice's phone. > > These are the kinds of things that can happen when we start thinking of > the overlay as a distributed database, not just as a distributed > proxy-registrar. > > -- > Dean > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 01 19:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IycYy-0003XJ-17; Sat, 01 Dec 2007 19:20:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IycYv-0003Vq-Ob for p2psip@ietf.org; Sat, 01 Dec 2007 19:19:57 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IycYu-0007Re-Ui for p2psip@ietf.org; Sat, 01 Dec 2007 19:19:57 -0500 Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lB20HImB020749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Dec 2007 19:17:18 -0500 (EST) Date: Sat, 1 Dec 2007 19:17:17 -0500 (EST) From: Salman Abdul Baset To: David Barrett Subject: Re: [P2PSIP] RE: plan B for NAT traversal for P2PSIP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: 'Henry Sinnreich' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Are you suggesting that plan B is "don't attempt direct connections between > NAT'd peers" and instead just to relay everything via the DHT? I think > that's a good fallback plan if a direct connection can't be established. This especially makes a lot of sense for iterative routing. Consider this: A peer gathers its address candidates and advertises them to its routing (finger) and neighbor (successor) peers. A node is likely to have three types of address candidates, namely, host, server-reflexive, and relay. In iterative routing, when a peer receives a request and it is not the responsible peer, it replies with the IP address of the next hop. It can also reply with all the address candidates of the next hop. The node can then try all the address candidates in a sequential or a parallel manner. I have used the parallel approach in my iterative implementation. Clearly, it has the overhead of number of parallel messages. However, the number of address candidates are typically no more than three. This overhead might be an acceptable compromise for successfuly communication. Note that relay addresses may also be needed in non-NAT scenarios. Think of two non-NAT machines which cannot communicate directly due to some firewall policy. Skype successfully performs communication between two non-NAT machines that cannot communicate directly. For media Skype allows relay connection (over TCP or UDP) in one direction and direct connections in other. Any connectivity scheme must address non-transitivity of communication that arises due to NAT or firewall policies. One can say that any NAT traversal scheme should perform as well as Skype's NAT traversal scheme. Can we say that ICE NAT traversal mechanism is as good as Skype? > Incidentally, also I'd toss out plan C: create a new NAT penetration > protocol that is "ICE-lite". > > > Basically, refine the best elements of ICE/STUN/TURN into a new protocol > that is simpler to implement and iteratively built in conjunction with > real-world testing (rather than designed first, tested later). I think ICE is well suited towards establishing long-lived connections such as media sessions or connections with routing or neighbor peers. However, when a peer needs to communicate only once with a peer behind a NAT, and this happens in iterative routing or when there is significant churn in the overlay, then we need to evaluate the ICE overhead in terms of connection setup delay and number of messages. The ease of implementation can also not be ignored. regards, Salman > > > > _____ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Friday, November 30, 2007 6:43 AM > To: Greger V. Teigre; David Barrett > Cc: Philip Matthews; P2PSIP Mailing List; bennylp@pjsip.org > Subject: plan B for NAT traversal for P2PSIP > > > > (I changed the Subject header) > > > > Greger, > > > > You have given us a valuable pointer to ICE NAT traversal at > > http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and > -turn/ where the implementer says: > > So Does It Work? > > Yes! (or, erm.. I think so!) > > The point is that if ICE does not work satisfactory, there must be a plan B > for NAT traversal for P2PSIP. > > Remember the WG assumption that most endpoints will be behind several levels > of NAT. > > We also want 100% success ratio as well as low call setup delay. > > > > One plan B is the model to just use an "openDHT-like overlay" as a service. > > Endpoints behind NAT may just work using one of several pre-provisioned or > discovered STUN/TURN servers, after which all the p2p happens as in the > openDHT. I believe ICE has a much better chance as well when two endpoints > have to just connect to the DHT. > > http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf > > > > Incidentally, the paper also shows the excellent security properties of this > approach when using the overlay in data mode. Look at Table1. > > > > I understand there are P2P SIP demos working exactly this way. > > > > There is no time to discuss plan B next week in the WG meeting, but don't > exclude the possibility it may happen sometimes later. > > > > Henry > > > > _____ > > From: Greger V. Teigre [mailto:greger@teigre.com] > Sent: Friday, November 30, 2007 2:46 AM > To: David Barrett > Cc: 'Philip Matthews'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver > > > > To ICE testing, the only data I have seen are from pjsip and only anecdotal. > > Cut from blog entry: > http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and > -turn/ > > "I've tried with running two pjsua's behind the same NAT that doesn't do > hairpin, and the local address pair is used. And trying two pjsua's behind > different NATs, the public address pair is used. So it looks like it's > working! > More over, I've been testing it since last week, and quite few bugs have > been found and fixed. And negotiation is pretty quick, around 100 ms with > two endpoints on different ADSL line, even though the SDP answer was delayed > in the proxy (ICE is able to start the checks early even when SDP answer > hasn't been received by caller). > But one of the major difficulties with testing ICE these days is practically > there is no other freely available ICE implementation out there (I mean, > ICE-14/15 compliant ones), so although ICE implementation in PJNATH does > seem to work, and it follows ICE-15 closely, we couldn't be sure that it is > compliant until it talks with other implementation. So if any of you know > one, please do let me know!" > > The implementation is documented here: > http://www.pjsip.org/pjnath/docs/html/index.htm > > The library was recently updated to the latest updates. I haven't seen any > larger scale testing yet. > g-) > > David Barrett wrote: > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: [P2PSIP] NAT Traversal Discussion in Vancouver > > 2) The very-low-level NAT Traversal approach is ICE, and I don't see > anyone questioning that. I don't think a discussion of this is worth > precious meeting time. > > > > Though it needn't be a topic of discussion, can you ask the attendees if > anybody has some real-world performance and reliability data on ICE that > they can share? I don't think any has been published to date, but perhaps > new data has come out since our last requests. > > Indeed, if anybody has this data (or can get it), this would be an excellent > time to share it. Specifically, I'm curious to know how long it typically > takes to set up a particular connection, and with what probability it can > establish a direct connection between two arbitrary peers on the internet. > ("Connection setup" and "peer connectivity") > > Thanks! > > -david > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 01 23:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyg2z-0007au-PD; Sat, 01 Dec 2007 23:03:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyg2y-0007ae-DO for p2psip@ietf.org; Sat, 01 Dec 2007 23:03:12 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iyg2v-0006KP-VD for p2psip@ietf.org; Sat, 01 Dec 2007 23:03:12 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSE00JT3LX98A@usaga01-in.huawei.com> for p2psip@ietf.org; Sat, 01 Dec 2007 20:03:09 -0800 (PST) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSE00LCZLX5O1@usaga01-in.huawei.com> for p2psip@ietf.org; Sat, 01 Dec 2007 20:03:09 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.64.136]) by szxmc03-in.huawei.com (mshttpd); Sun, 02 Dec 2007 12:03:00 +0800 Date: Sun, 02 Dec 2007 12:03:00 +0800 From: jiangxingfeng 36340 Subject: =?gb2312?B?u9i4tA==?=:Re: [P2PSIP] RE: plan B for NAT traversal for P2PSIP In-reply-to: To: Salman Abdul Baset Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: X-Spam-Score: 1.3 (+) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: 'Henry Sinnreich' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > Are you suggesting that plan B is "don't attempt direct > connections between > > NAT'd peers" and instead just to relay everything via the DHT? > I think > > that's a good fallback plan if a direct connection can't be > established. > This especially makes a lot of sense for iterative routing. > > Consider this: A peer gathers its address candidates and > advertises them > to its routing (finger) and neighbor (successor) peers. A node is > likely > to have three types of address candidates, namely, host, server- > reflexive, > and relay. In iterative routing, when a peer receives a request > and it is > not the responsible peer, it replies with the IP address of the > next hop. > It can also reply with all the address candidates of the next hop. > The > node can then try all the address candidates in a sequential or a > parallel > manner. > > I have used the parallel approach in my iterative implementation. > Clearly, > it has the overhead of number of parallel messages. However, the > number > of address candidates are typically no more than three. This > overhead > might be an acceptable compromise for successfuly communication. > I have a question here: if my understanding is right, most of the NATs have a property of address dependent filtering. How could you contact with the peer by using its candidate without using any hole-punching technique first? > I think ICE is well suited towards establishing long-lived > connections > such as media sessions or connections with routing or neighbor > peers. > However, when a peer needs to communicate only once with a peer > behind a > NAT, and this happens in iterative routing or when there is > significant > churn in the overlay, then we need to evaluate the ICE overhead in > terms > of connection setup delay and number of messages. The ease of > implementation can also not be ignored. > yes, i agree. In SEP, we also use relaying peer to get the response directly back to the source peer without ICE negotiation. > > _____ > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Friday, November 30, 2007 6:43 AM > > To: Greger V. Teigre; David Barrett > > Cc: Philip Matthews; P2PSIP Mailing List; bennylp@pjsip.org > > Subject: plan B for NAT traversal for P2PSIP > > > > > > > > (I changed the Subject header) > > > > > > > > Greger, > > > > > > > > You have given us a valuable pointer to ICE NAT traversal at > > > > http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source- > ice-stun-and > > -turn/ where the implementer says: > > > > So Does It Work? > > > > Yes! (or, erm.. I think so!) > > > > The point is that if ICE does not work satisfactory, there must > be a plan B > > for NAT traversal for P2PSIP. > > > > Remember the WG assumption that most endpoints will be behind > several levels > > of NAT. > > > > We also want 100% success ratio as well as low call setup delay. > > > > > > > > One plan B is the model to just use an "openDHT-like overlay" as > a service. > > > > Endpoints behind NAT may just work using one of several pre- > provisioned or > > discovered STUN/TURN servers, after which all the p2p happens as > in the > > openDHT. I believe ICE has a much better chance as well when two > endpoints> have to just connect to the DHT. > > > > http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf > > > > > > > > Incidentally, the paper also shows the excellent security > properties of this > > approach when using the overlay in data mode. Look at Table1. > > > > > > > > I understand there are P2P SIP demos working exactly this way. > > > > > > > > There is no time to discuss plan B next week in the WG meeting, > but don't > > exclude the possibility it may happen sometimes later. > > > > > > > > Henry > > > > > > > > _____ > > > > From: Greger V. Teigre [mailto:greger@teigre.com] > > Sent: Friday, November 30, 2007 2:46 AM > > To: David Barrett > > Cc: 'Philip Matthews'; 'P2PSIP Mailing List' > > Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver > > > > > > > > To ICE testing, the only data I have seen are from pjsip and > only anecdotal. > > > > Cut from blog entry: > > http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source- > ice-stun-and > > -turn/ > > > > "I've tried with running two pjsua's behind the same NAT that > doesn't do > > hairpin, and the local address pair is used. And trying two > pjsua's behind > > different NATs, the public address pair is used. So it looks > like it's > > working! > > More over, I've been testing it since last week, and quite few > bugs have > > been found and fixed. And negotiation is pretty quick, around > 100 ms with > > two endpoints on different ADSL line, even though the SDP answer > was delayed > > in the proxy (ICE is able to start the checks early even when > SDP answer > > hasn't been received by caller). > > But one of the major difficulties with testing ICE these days is > practically> there is no other freely available ICE implementation > out there (I mean, > > ICE-14/15 compliant ones), so although ICE implementation in > PJNATH does > > seem to work, and it follows ICE-15 closely, we couldn't be sure > that it is > > compliant until it talks with other implementation. So if any of > you know > > one, please do let me know!" > > > > The implementation is documented here: > > http://www.pjsip.org/pjnath/docs/html/index.htm > > > > The library was recently updated to the latest updates. I > haven't seen any > > larger scale testing yet. > > g-) > > > > David Barrett wrote: > > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Subject: [P2PSIP] NAT Traversal Discussion in Vancouver > > > > 2) The very-low-level NAT Traversal approach is ICE, and I don't see > > anyone questioning that. I don't think a discussion of this is worth > > precious meeting time. > > > > > > > > Though it needn't be a topic of discussion, can you ask the > attendees if > > anybody has some real-world performance and reliability data on > ICE that > > they can share? I don't think any has been published to date, > but perhaps > > new data has come out since our last requests. > > > > Indeed, if anybody has this data (or can get it), this would be > an excellent > > time to share it. Specifically, I'm curious to know how long it > typically> takes to set up a particular connection, and with what > probability it can > > establish a direct connection between two arbitrary peers on the > internet.> ("Connection setup" and "peer connectivity") > > > > Thanks! > > > > -david > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 02 11:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iys9p-0005H9-88; Sun, 02 Dec 2007 11:59:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iys9n-0005BX-SB for p2psip@ietf.org; Sun, 02 Dec 2007 11:59:03 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iys9n-0000al-IV for p2psip@ietf.org; Sun, 02 Dec 2007 11:59:03 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2007 08:59:03 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lB2Gx2xY025072; Sun, 2 Dec 2007 08:59:02 -0800 Received: from [130.129.21.174] (sjc-vpn7-273.cisco.com [10.21.145.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB2Gvo1n029140; Sun, 2 Dec 2007 16:59:02 GMT In-Reply-To: <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> <47509618.7060001@cisco.com> <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A3B78B9-2118-4000-B06B-01D38A05F15F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Sun, 2 Dec 2007 07:44:13 -0800 To: Dean Willis X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=377; t=1196614742; x=1197478742; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20More=20thoughts=20on=20clients, =20peers, =2 0and=20services,=09and=20service=20routing |Sender:=20; bh=Iu7/+2hwb9vgu1SwoNY85UKtqMPWlOXnGqoJvHAAfFY=; b=mVRVeu6AYbzv14aJao/2tsL4QjOG+kH+rlEjCn0HI2Bx5e4ZW2LpYurYG/62F0SDIEwo8nUr JG0QvqIJjF/rxYIYIBQLY0BuIrCyivAQfmtt8aO0vnieGqwB50MLTadQ; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 30, 2007, at 6:27 PM, Dean Willis wrote: > > On Nov 30, 2007, at 5:00 PM, Paul Kyzivat wrote: > >> Dean, >> >> Very interesting stuff you wrote below. > > Thanks. I think "interesting" is a good adjective. Far more polite > than "deranged", which probably came to mind for at least a few > readers. Thanks - I understand better now what you meant. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 02 13:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytCb-0002vt-Hx; Sun, 02 Dec 2007 13:06:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytCa-0002uy-9d for p2psip@ietf.org; Sun, 02 Dec 2007 13:06:00 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IytCZ-0000QF-Ar for p2psip@ietf.org; Sun, 02 Dec 2007 13:06:00 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB2I5fF5005981; Sun, 2 Dec 2007 20:05:50 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:04:54 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:04:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Client discussion in Vancouver Date: Sun, 2 Dec 2007 20:07:50 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F0581B49D@esebe102.NOE.Nokia.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE373@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Client discussion in Vancouver Thread-Index: AcgzuHuQE+bcMuT1QNyK9HOLLqxPpAAbCGggADkcuNA= References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE373@namail5.corp.adobe.com> From: To: , X-OriginalArrivalTime: 02 Dec 2007 18:04:54.0361 (UTC) FILETIME=[D7557C90:01C8350D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0714993283==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0714993283== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8350D.D6FF5840" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8350D.D6FF5840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Henry, =20 Thanks for your comments! Answers inline... =20 ________________________________ From: ext Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: 01 December, 2007 06:39 To: Matuszewski Marcin (Nokia-NRC/Helsinki); p2psip@ietf.org Subject: RE: [P2PSIP] Client discussion in Vancouver =09 =09 I suggest edits for two items: =20 * A device should become a peer whenever possible=20 =20 This is not always possible or desirable in certain usage scenarios =20 I agree that it is not always possible or desirable for a device to become a peer. The idea behind this sentence is that a device should become a peer, subject to resource constraints, policy, security and a charging model. =20 =20 * Resource limitations + churn/intermittent connectivity make a poor peer=20 =20 Replace "poor " with "undesirable", since the churn on the overlay outweighs the benefit of having this peer.=20 This is the reason why small mobile devices may be undesirable peers. Some analytical work with numbers would be helpful here. =20 Ok I will modify it. =20 Henry =20 =20 Marcin =20 =09 ________________________________ From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]=20 Sent: Friday, November 30, 2007 7:21 PM To: p2psip@ietf.org Subject: [P2PSIP] Client discussion in Vancouver =20 =20 Hi all,=20 Please see a draft version of the presentation about clients. Any comments appreciated!=20 http://netlabathut.googlepages.com/Clients_02.ppt =20 Marcin=20 ------_=_NextPart_001_01C8350D.D6FF5840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Client = discussion in Vancouver
Hi Henry,
 
Thanks for your comments! Answers=20 inline...
 

From: ext Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: 01 December, 2007=20 06:39
To: Matuszewski Marcin (Nokia-NRC/Helsinki);=20 p2psip@ietf.org
Subject: RE: [P2PSIP] Client discussion in=20 Vancouver

I suggest = edits for=20 two items:

 

  • A device should become = a peer=20 whenever possible

 

This is not = always=20 possible or desirable in certain usage = scenarios

 

I agree that it is not always = possible or=20 desirable for a device to become a peer. The idea behind=20 this sentence is that a device should become a peer, subject = to=20 resource constraints, policy, security and a charging=20 model.   

 

  • Resource limitations + = churn/intermittent connectivity make a poor = peer=20

 

Replace = “poor “ with=20 “undesirable”, since the churn on the overlay outweighs = the benefit of having=20 this peer.

This is the = reason=20 why small mobile devices may be undesirable peers. Some analytical = work with=20 numbers would be helpful here.

 

Ok I will modify=20 it.

 

Henry

 

 

Marcin

 

From:=20 marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]=20
Sent: Friday, = November 30,=20 2007 7:21 PM
To:=20 p2psip@ietf.org
Subject: [P2PSIP] Client = discussion in=20 Vancouver

=

 

 

Hi all,=20

Please see a draft = version of the=20 presentation about clients. Any comments appreciated! =
http://netlabathut.googlepages.com/Clients_02.ppt=20

Marcin=20

------_=_NextPart_001_01C8350D.D6FF5840-- --===============0714993283== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0714993283==-- From p2psip-bounces@ietf.org Sun Dec 02 13:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytZi-000119-Bw; Sun, 02 Dec 2007 13:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytZg-0000z4-Iy for p2psip@ietf.org; Sun, 02 Dec 2007 13:29:52 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IytZe-0003hv-Lq for p2psip@ietf.org; Sun, 02 Dec 2007 13:29:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB2ITDDl018577; Sun, 2 Dec 2007 20:29:35 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:29:19 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:29:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Client discussion in Vancouver Date: Sun, 2 Dec 2007 20:32:16 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F0581B49E@esebe102.NOE.Nokia.com> In-Reply-To: <7b683f3f0711302107g5ac95623gdc0d601af579c094@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Client discussion in Vancouver Thread-Index: Acgz2B/CJ6ubxxDnTCm+ukkmpzD4HgBNlWfQ References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> <7b683f3f0711302107g5ac95623gdc0d601af579c094@mail.gmail.com> From: To: , X-OriginalArrivalTime: 02 Dec 2007 18:29:19.0272 (UTC) FILETIME=[407D2A80:01C83511] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Dean, I agree with Eunsoo. The idea is to decouple the service layer from the overlay layer. As Eunsoo wrote there is a fundamental difference between clients and peers on the overlay layer, whereas the difference between peers and clients on the service layer depends on a use case scenario. We can discuss use cases forever and do not cover all of them.=20 I will show some results of measurements.=20 Marcin =20 >-----Original Message----- >From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 >Sent: 30 November, 2007 21:08 >To: Dean Willis >Cc: Matuszewski Marcin (Nokia-NRC/Helsinki); p2psip@ietf.org >Subject: Re: [P2PSIP] Client discussion in Vancouver > >The fundamental difference between Peer and Client? >Peers do something (overlay maintenance and routing) Clients do not it. >That's why the slides use the analogy of saying Peers are 'routing' >nodes and Clients are 'non-routing' nodes. > >Don't look for what Peers do differently from Clients. >Look for what Peers do that Clients do not. > >Thanks. > >Eunsoo > > >On Nov 30, 2007 9:29 PM, Dean Willis wrote: >> >> On Nov 30, 2007, at 7:21 PM, >> >> wrote: >> >> > >> > Hi all, >> > >> > Please see a draft version of the presentation about clients. Any=20 >> > comments appreciated! >> > http://netlabathut.googlepages.com/Clients_02.ppt >> > >> >> This still doesn't say a lot about what peers really do differently=20 >> from clients. Perhaps it would be better expressed as a set of use=20 >> cases? >> >> -- >> Dean >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > >-- >Eunsoo > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 02 13:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iytqq-0004QT-14; Sun, 02 Dec 2007 13:47:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iytqo-0004Km-HM for p2psip@ietf.org; Sun, 02 Dec 2007 13:47:34 -0500 Received: from maile.telecomitalia.it ([156.54.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iytqn-0005qZ-Vg for p2psip@ietf.org; Sun, 02 Dec 2007 13:47:34 -0500 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:47:32 +0100 Received: from ptpxch004ba020.idc.cww.telecomitalia.it ([156.54.240.43]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:47:32 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 19:47:30 +0100 Message-ID: <4752FE1D.2070401@telecomitalia.it> Date: Sun, 02 Dec 2007 10:49:01 -0800 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] Client discussion in Vancouver References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> <7b683f3f0711302107g5ac95623gdc0d601af579c094@mail.gmail.com> <3F18E76823C95E4795181D74BAC7664F0581B49E@esebe102.NOE.Nokia.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F0581B49E@esebe102.NOE.Nokia.com> X-OriginalArrivalTime: 02 Dec 2007 18:47:30.0962 (UTC) FILETIME=[CB2FD720:01C83513] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075600181==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1075600181== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090300000709040709040100" This is a cryptographically signed message in MIME format. --------------ms090300000709040709040100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit marcin.matuszewski@nokia.com wrote: > The idea is to decouple the service layer from the overlay layer. As > Eunsoo wrote there is a fundamental difference between clients and peers > on the overlay layer, whereas the difference between peers and clients > on the service layer depends on a use case scenario. We can discuss use > cases forever and do not cover all of them. > > I will show some results of measurements. It is quite clear what people advocating for clients think the difference between clients and peers is. The issue is _why_ do we need to define clients. If the only reason is "because clients need to perform GET operations to find user contacts to send SIP messages to, without being involved in routing and overlay maintainance", well, that's probably not enough a reason because, as it has been shown, the same result is achievable by making non-peer nodes simply acting as pure SIP UAs. If you have other use cases in mind, it is probably worth to discuss them during the live meeting. -- Ciao, Enrico --------------ms090300000709040709040100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMjAyMTg0OTAxWjAjBgkqhkiG9w0BCQQxFgQUshysrs9W pSJnXEdwyV+3VvQ1tBYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAF1Ln3Y7ZBiVH7c3VgNBIjHKwgk9p9JgOMZuohUmvohlMRO+7O3YShJd UTVSy6Bqv9wsKqH0c0+kD35MD1tyGaMDuiIhuObwqbIJRUjEBFCkA5Tlz8wkwJDAwupc63xT OJlbv4lAT1OJoxs0YtmSj2QR5PcV/Z6jIdXV+x4uhrd1dxDPciCGo0RrIVozgEzs/I1TUG/u DH4mqk4IcnPf2Ta+Pr4AIDOWX4I5XNhzyzYayhzHWUbphqcOQjQzO+erk9j1XIB6TcEaDexy vgyyNv+PDJFljceE2tfjXKkd8q1hl8qsUVgULYdPGBmSnWSPXgytbhcSwerAXYOPuzKxGo8A AAAAAAA= --------------ms090300000709040709040100-- --===============1075600181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1075600181==-- From p2psip-bounces@ietf.org Sun Dec 02 14:21:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuO0-0001UT-DK; Sun, 02 Dec 2007 14:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuNy-0001QU-9r for p2psip@ietf.org; Sun, 02 Dec 2007 14:21:50 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyuNx-000235-ME for p2psip@ietf.org; Sun, 02 Dec 2007 14:21:50 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB2JLjhB032137; Sun, 2 Dec 2007 21:21:45 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:21:41 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 21:21:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Client discussion in Vancouver Date: Sun, 2 Dec 2007 21:24:38 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F0581B4A6@esebe102.NOE.Nokia.com> In-Reply-To: <4752FE1D.2070401@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Client discussion in Vancouver Thread-Index: Acg1E9ni0j27Qtg0QImBCIXSh8b+igABANqA References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> <7b683f3f0711302107g5ac95623gdc0d601af579c094@mail.gmail.com> <3F18E76823C95E4795181D74BAC7664F0581B49E@esebe102.NOE.Nokia.com> <4752FE1D.2070401@telecomitalia.it> From: To: X-OriginalArrivalTime: 02 Dec 2007 19:21:41.0517 (UTC) FILETIME=[9169B3D0:01C83518] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 Hi Enrico, Did you have time to look at the slides about the client node type I sent on Friday? The slides 2-3 discuss the differences between a SIP UA and a client. Please let me know if something is unclear or should be changed.=20 Marcin >-----Original Message----- >From: ext Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 >Sent: 02 December, 2007 10:49 >To: Matuszewski Marcin (Nokia-NRC/Helsinki) >Cc: eunsooshim@gmail.com; dean.willis@softarmor.com; p2psip@ietf.org >Subject: Re: [P2PSIP] Client discussion in Vancouver > >marcin.matuszewski@nokia.com wrote: >> The idea is to decouple the service layer from the overlay layer. As=20 >> Eunsoo wrote there is a fundamental difference between clients and=20 >> peers on the overlay layer, whereas the difference between peers and=20 >> clients on the service layer depends on a use case scenario. We can=20 >> discuss use cases forever and do not cover all of them. >>=20 >> I will show some results of measurements.=20 > >It is quite clear what people advocating for clients think the=20 >difference between clients and peers is. The issue is _why_=20 >do we need to define clients. If the only reason is "because=20 >clients need to perform GET operations to find user contacts=20 >to send SIP messages to, without being involved in routing and=20 >overlay maintainance", well, that's probably not enough a=20 >reason because, as it has been shown, the same result is=20 >achievable by making non-peer nodes simply acting as pure SIP=20 >UAs. If you have other use cases in mind, it is probably=20 >worth to discuss them during the live meeting. > >-- >Ciao, >Enrico > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 02 14:34:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuaO-0008Ga-O8; Sun, 02 Dec 2007 14:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuaN-0008Bb-S0 for p2psip@ietf.org; Sun, 02 Dec 2007 14:34:39 -0500 Received: from maill.telecomitalia.it ([217.169.121.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyuaN-0003qQ-4B for p2psip@ietf.org; Sun, 02 Dec 2007 14:34:39 -0500 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:34:38 +0100 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:34:37 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 20:34:36 +0100 Message-ID: <47530925.9050404@telecomitalia.it> Date: Sun, 02 Dec 2007 11:36:05 -0800 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] Client discussion in Vancouver References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> <7b683f3f0711302107g5ac95623gdc0d601af579c094@mail.gmail.com> <3F18E76823C95E4795181D74BAC7664F0581B49E@esebe102.NOE.Nokia.com> <4752FE1D.2070401@telecomitalia.it> <3F18E76823C95E4795181D74BAC7664F0581B4A6@esebe102.NOE.Nokia.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F0581B4A6@esebe102.NOE.Nokia.com> X-OriginalArrivalTime: 02 Dec 2007 19:34:36.0347 (UTC) FILETIME=[5F3F60B0:01C8351A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1049979251==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1049979251== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050506010500060209010502" This is a cryptographically signed message in MIME format. --------------ms050506010500060209010502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit marcin.matuszewski@nokia.com wrote: > Did you have time to look at the slides about the client node type I > sent on Friday? > The slides 2-3 discuss the differences between a SIP UA and a client. > Please let me know if something is unclear or should be changed. Yes, I did read the slides as well as many of the discussions happened on the list and during the last five meetings. It is probably clear to most of the people in the group what you mean by "client" and what's the difference between clients, peers and SIP user agents. What's probably not so clear, at least to me, is in which cases such a differentiation is important. Do you think having clients (other than SIP UAs) is important to implement overlay-based services such as voice-mail or certificate/key repository for which SIP is not enough? It may be reasonable, but we really need a list of them to base a discussion on. -- Ciao, Enrico --------------ms050506010500060209010502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMjAyMTkzNjA1WjAjBgkqhkiG9w0BCQQxFgQU3rNE7P0N soGSxLJq7g+xgwPzOOowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAHHX9Qeh9FFPEL4IptwCubASVZg93b+8YJMzfBTanM0cJIbbEZ0ONYYu W6as+5BSCpnMvPVb8gBnNfjSzy5b3irWWaSGwLlX8Zzz7GLVUPsEQgB6zhL2AZpFCXy/l2an 9J4yxbcCRcYxQ/2m2VolNE1JF6c/N2Ug1xxleXLRiu/uMh4EBzC41Bmi+1a0qh59nu//+b2C ozopYN6XSfkcr0tkWELPZncPlyGos4Cr4IhAkoJsrjMKy2KNbaT7IUc6cKjd+AwJFgYgCKSO anxl/dXDne2D3n8i+ij3raXLHL1ZDNsfBEDljOx6Mf7pgpl1XxDxrBkyZVL/xZH9wkEUj9UA AAAAAAA= --------------ms050506010500060209010502-- --===============1049979251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1049979251==-- From p2psip-bounces@ietf.org Sun Dec 02 16:39:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywX0-0007He-8J; Sun, 02 Dec 2007 16:39:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywWy-0007Gk-9d for p2psip@ietf.org; Sun, 02 Dec 2007 16:39:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IywWx-0002yI-TK for p2psip@ietf.org; Sun, 02 Dec 2007 16:39:16 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2007 13:39:15 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB2LdFfX018427; Sun, 2 Dec 2007 13:39:15 -0800 Received: from [130.129.21.174] (sjc-vpn2-1266.cisco.com [10.21.116.242]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB2LdA75007348; Sun, 2 Dec 2007 21:39:11 GMT In-Reply-To: <474E2A8B.2060403@idssoftware.com> References: <474E2A8B.2060403@idssoftware.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06853EF9-E4C7-41F1-B698-C36DA3A0E9EC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02 Date: Sun, 2 Dec 2007 13:39:04 -0800 To: Michael Chen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1461; t=1196631555; x=1197495555; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Merge=20of=20ASP=20and=20RELOAD=20-=20Vers ion=20Notification=20for=09draft-bryan-p2psip-reload-02 |Sender:=20; bh=KvqVCuQvuob/CC/b6CKk0Ny6qitZICZv0xeTwHAdqBE=; b=YX1SpX/9YaoWoiUE9NCSCt76c9afRTMfym2qIGaHeEJCbi8HDVPm0OkMcWKcSzNxmNjnveBK gHH0zbfaExpM5om3+dDK5wEvNnhfFSH9iuTGj8Fo3Rz906YDpFjPvUvX8WmKMSK/fbycoe2689 6niv6tggvawA71SHNdb4eSIuk=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 28, 2007, at 6:57 PM, Michael Chen wrote: > > I don't see where the protocol sends the originator's peer-ID. At > the end of section 4.1, it says the via list starts out empty and > the route list has the intermediate and destination peer IDs. Say > A wants to reach C through B, then in the forwarding header sent by > A, the route-list contains [B, C], and the via list is empty. > Where does C or B for that matter know the peer ID of A when it's > time to send the respond back? > > Should the via-list in the forwarding header sent by A contains the > peer ID of A? Yes, we do need the A to get in the list, but the ID is inserted by B. The logic behind this had to do with some security issues and logic about what B inserts. B actually inserts the peer it perceives the message came from. This helps with spoofing return routes by having responses go to where they came from. Sorry this email is brief, I will try and write a clearer one if this does make sense. > > Also, any comment of my earlier suggestion in this thread about > swapping the position of the via list and route list? sorry for slow reply on this - yes - I think this is a good idea. I want to talk to co-authors about it and then put it in the next version the draft. I had not got the time to do this yet and I was leaving your email in my inbox as a TODO reminder. Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 02 23:21:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2o8-0002tc-FF; Sun, 02 Dec 2007 23:21:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2o7-0002rC-L7 for p2psip@ietf.org; Sun, 02 Dec 2007 23:21:23 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz2o5-0006PX-VL for p2psip@ietf.org; Sun, 02 Dec 2007 23:21:23 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSG007RNHE941@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 12:20:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSG0000ZHE776@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 12:20:33 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSG002Q8HE7VN@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 12:20:31 +0800 (CST) Date: Mon, 03 Dec 2007 12:20:32 +0800 From: Song Yongchao Subject: RE: Re: [P2PSIP] RE: plan B for NAT traversal forP2PSIP In-reply-to: To: 'jiangxingfeng 36340' , 'Salman Abdul Baset' Message-id: <001b01c83563$d8525d10$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acg0mFN2rgnIR1AaRAKNhultdceDNQAyKkhw X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: 'Henry Sinnreich' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip! I think there is another question to be discussed. If a joining peer can't setup a direct connection with its neighbor, it = can use a relay to relay messages to its neighbor, but at the same time, = this adds another "hop" in the overlay routing. If a lot of peers communicate with those peers in their neighbor table through relays, the overlay = routing may be very low efficient because the requests must route through some additional relays in the routing path. Then, a joining peer that can't setup enough direct connections to its neighbors should not be admitted as a Peer? Best Regards! Song Yongchao > -----Original Message----- > From: jiangxingfeng 36340 [mailto:jiang.x.f@huawei.com] > Sent: Sunday, December 02, 2007 12:03 PM > To: Salman Abdul Baset > Cc: 'Henry Sinnreich'; 'Philip Matthews'; 'P2PSIP Mailing List' > Subject: =BB=D8=B8=B4:Re: [P2PSIP] RE: plan B for NAT traversal = forP2PSIP >=20 > > > Are you suggesting that plan B is "don't attempt direct > > connections between > > > NAT'd peers" and instead just to relay everything via the DHT? > > I think > > > that's a good fallback plan if a direct connection can't be > > established. > > This especially makes a lot of sense for iterative routing. > > > > Consider this: A peer gathers its address candidates and > > advertises them > > to its routing (finger) and neighbor (successor) peers. A node is > > likely > > to have three types of address candidates, namely, host, server- > > reflexive, > > and relay. In iterative routing, when a peer receives a request > > and it is > > not the responsible peer, it replies with the IP address of the > > next hop. > > It can also reply with all the address candidates of the next hop. > > The > > node can then try all the address candidates in a sequential or a > > parallel > > manner. > > > > I have used the parallel approach in my iterative implementation. > > Clearly, > > it has the overhead of number of parallel messages. However, the > > number > > of address candidates are typically no more than three. This > > overhead > > might be an acceptable compromise for successfuly communication. > > >=20 > I have a question here: if my understanding is right, most of the NATs have > a property of address dependent filtering. > How could you contact with the peer by using its candidate without = using any > hole-punching technique first? >=20 >=20 >=20 > > I think ICE is well suited towards establishing long-lived > > connections > > such as media sessions or connections with routing or neighbor > > peers. > > However, when a peer needs to communicate only once with a peer > > behind a > > NAT, and this happens in iterative routing or when there is > > significant > > churn in the overlay, then we need to evaluate the ICE overhead in > > terms > > of connection setup delay and number of messages. The ease of > > implementation can also not be ignored. > > >=20 > yes, i agree. In SEP, we also use relaying peer to get the response directly > back to the source peer without ICE negotiation. >=20 >=20 > > > _____ > > > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Friday, November 30, 2007 6:43 AM > > > To: Greger V. Teigre; David Barrett > > > Cc: Philip Matthews; P2PSIP Mailing List; bennylp@pjsip.org > > > Subject: plan B for NAT traversal for P2PSIP > > > > > > > > > > > > (I changed the Subject header) > > > > > > > > > > > > Greger, > > > > > > > > > > > > You have given us a valuable pointer to ICE NAT traversal at > > > > > > http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source- > > ice-stun-and > > > -turn/ where the implementer says: > > > > > > So Does It Work? > > > > > > Yes! (or, erm.. I think so!) > > > > > > The point is that if ICE does not work satisfactory, there must > > be a plan B > > > for NAT traversal for P2PSIP. > > > > > > Remember the WG assumption that most endpoints will be behind > > several levels > > > of NAT. > > > > > > We also want 100% success ratio as well as low call setup delay. > > > > > > > > > > > > One plan B is the model to just use an "openDHT-like overlay" as > > a service. > > > > > > Endpoints behind NAT may just work using one of several pre- > > provisioned or > > > discovered STUN/TURN servers, after which all the p2p happens as > > in the > > > openDHT. I believe ICE has a much better chance as well when two > > endpoints> have to just connect to the DHT. > > > > > > http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf > > > > > > > > > > > > Incidentally, the paper also shows the excellent security > > properties of this > > > approach when using the overlay in data mode. Look at Table1. > > > > > > > > > > > > I understand there are P2P SIP demos working exactly this way. > > > > > > > > > > > > There is no time to discuss plan B next week in the WG meeting, > > but don't > > > exclude the possibility it may happen sometimes later. > > > > > > > > > > > > Henry > > > > > > > > > > > > _____ > > > > > > From: Greger V. Teigre [mailto:greger@teigre.com] > > > Sent: Friday, November 30, 2007 2:46 AM > > > To: David Barrett > > > Cc: 'Philip Matthews'; 'P2PSIP Mailing List' > > > Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver > > > > > > > > > > > > To ICE testing, the only data I have seen are from pjsip and > > only anecdotal. > > > > > > Cut from blog entry: > > > http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source- > > ice-stun-and > > > -turn/ > > > > > > "I've tried with running two pjsua's behind the same NAT that > > doesn't do > > > hairpin, and the local address pair is used. And trying two > > pjsua's behind > > > different NATs, the public address pair is used. So it looks > > like it's > > > working! > > > More over, I've been testing it since last week, and quite few > > bugs have > > > been found and fixed. And negotiation is pretty quick, around > > 100 ms with > > > two endpoints on different ADSL line, even though the SDP answer > > was delayed > > > in the proxy (ICE is able to start the checks early even when > > SDP answer > > > hasn't been received by caller). > > > But one of the major difficulties with testing ICE these days is > > practically> there is no other freely available ICE implementation > > out there (I mean, > > > ICE-14/15 compliant ones), so although ICE implementation in > > PJNATH does > > > seem to work, and it follows ICE-15 closely, we couldn't be sure > > that it is > > > compliant until it talks with other implementation. So if any of > > you know > > > one, please do let me know!" > > > > > > The implementation is documented here: > > > http://www.pjsip.org/pjnath/docs/html/index.htm > > > > > > The library was recently updated to the latest updates. I > > haven't seen any > > > larger scale testing yet. > > > g-) > > > > > > David Barrett wrote: > > > > > > -----Original Message----- > > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > > Subject: [P2PSIP] NAT Traversal Discussion in Vancouver > > > > > > 2) The very-low-level NAT Traversal approach is ICE, and I don't = see > > > anyone questioning that. I don't think a discussion of this is = worth > > > precious meeting time. > > > > > > > > > > > > Though it needn't be a topic of discussion, can you ask the > > attendees if > > > anybody has some real-world performance and reliability data on > > ICE that > > > they can share? I don't think any has been published to date, > > but perhaps > > > new data has come out since our last requests. > > > > > > Indeed, if anybody has this data (or can get it), this would be > > an excellent > > > time to share it. Specifically, I'm curious to know how long it > > typically> takes to set up a particular connection, and with what > > probability it can > > > establish a direct connection between two arbitrary peers on the > > internet.> ("Connection setup" and "peer connectivity") > > > > > > Thanks! > > > > > > -david > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 02 23:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3Ln-0007Np-0w; Sun, 02 Dec 2007 23:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3Ll-0007LN-H6 for p2psip@ietf.org; Sun, 02 Dec 2007 23:56:09 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz3Lk-0000a7-3i for p2psip@ietf.org; Sun, 02 Dec 2007 23:56:09 -0500 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) (user=sa2086 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lB34u4b7004703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 Dec 2007 23:56:07 -0500 (EST) Date: Sun, 2 Dec 2007 23:56:04 -0500 (EST) From: Salman Abdul Baset To: p2psip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [P2PSIP] 500+ Node Overlay using P2PP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have implemented Kademlia and Bamboo over P2PP and are currently running a 500+ node overlay on 160+ planet lab machines. The implementation uses the reliability model of P2PP and is compliant to P2PP-01 draft. We have overlayed the routing and resource tables of nodes on google map. The routing and resource tables of 160 live nodes can be viewed at: http://www1.cs.columbia.edu/~gg2265/kad3/ The display script is a bit slow and we are working to improve it. A rendering from an earlier run of 50 nodes can be found at: http://www1.cs.columbia.edu/~salman/p2pp/planet/ I plan to release a 'client' executable very soon which folks can use to insert key value pairs in the overlay and view the results immediately on nodes. Regards, Salman _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 00:13:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3c8-0008Mc-Uj; Mon, 03 Dec 2007 00:13:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3c7-0008GL-H4 for p2psip@ietf.org; Mon, 03 Dec 2007 00:13:03 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz3c6-0002JH-DP for p2psip@ietf.org; Mon, 03 Dec 2007 00:13:03 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C50D033C47 for ; Sun, 2 Dec 2007 21:07:44 -0800 (PST) Date: Sun, 02 Dec 2007 21:07:44 -0800 From: Eric Rescorla To: p2psip@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sun_Dec__2_21:07:44_2007-1" Message-Id: <20071203050744.C50D033C47@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 17f3fe1c4bc9ac88f6fb2eb30c70dacb Subject: [P2PSIP] Initial slides for Wednesday X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org --Multipart_Sun_Dec__2_21:07:44_2007-1 Content-Type: text/plain; charset=US-ASCII Here are my prototype slides for Tuesday's discussion. -Ekr --Multipart_Sun_Dec__2_21:07:44_2007-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="p2psip-slides.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKMyAwIG9iaiA8PAovTGVuZ3RoIDM3NiAgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCnjaVVFNb8IwDL3nV+TYHpLFTtK0tzENJDhM3egNcUAlmxBfWgHx92enFIYq JY5rPz+/h9oEJw19eI/avXhrxMsEnYSgEbyTzbcsQIOV6JyunClks15k89heupgrCy6rcwxZjF2u IFPTd07abHQ68XuTQ/bDwYGCPQeRgsO5L9oc+rvGej6t82Uzo9FWAujKe+TRVanRGyuVr3Thy374 uNu01EhTv2Ka0h5zLLNut2IIqaDQBjCkwPkSU9NH5MozF16Z8JGPjshsn6COTG91aHuqPaPiPyOF hcbC+Gf0uKW+7pWbecHzlXG6lCRcguX9V3y0UeeJMetB+GLcCEjig3RW28qiJGRfVezGr1gsjVwL I2fCaCytl1d6GA0OgtwLrDybB0NmJ+bi846nBkD1QEz+2iDJzJJcpY2GolKXeFtnOm4mJIt3WTCk RED0bDmLckk78U9PzlvDzveuU2KUNDxtHpbH5DUBJa/pvnmt0ARqhkGCP175leBlbmRzdHJlYW0K ZW5kb2JqCjIgMCBvYmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDMgMCBSCi9SZXNvdXJjZXMg MSAwIFIKL01lZGlhQm94IFswIDAgNzkxLjk5OTQgNjExLjk5OTZdCi9QYXJlbnQgMTYgMCBSCj4+ IGVuZG9iagoxIDAgb2JqIDw8Ci9Gb250IDw8IC9GMjQgNiAwIFIgL0YyMyA5IDAgUiAvRjI2IDEy IDAgUiAvRjM3IDE1IDAgUiA+PgovUHJvY1NldCBbIC9QREYgL1RleHQgXQo+PiBlbmRvYmoKMTkg MCBvYmogPDwKL0xlbmd0aCA1NjMgICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp42q1US2vbQBC+61fscQXRZp/S7qnEJAbn0LpYh0Cag2wrlkgsubIcY/rnO/tyEnChheLD7ozn +3a+eYgTWkhE4cfPt9U2mZTJ9VRoxBgxSnFUPiOmNJGKGcSlJsqIHJXrRzypVi+boT906/SpvL+e MokMMTnPLSRjtCBUa4UyCV7DmMP8oKzw0Zx/iHa3At63MV/rNGO4XqeZEAKPvT0lXqYZL3DtjSpl ePkaDB8hcHUA72ixDVwcSWc97cpeLWSMiKYaA8Yfu0gOuMG7mmr/KWTTvgVKZ86A7tYrgVq9KxFE 6lyD/JwYrbzoXxcUM0pkTnWQ/G1s6uHY7l0Cn559q1Ku8dDWoz1PPv/+2f85QBL9YWy7TcCMI/Rk H2vEDR6CYi+wdw/s2yXgoHoXusYFMYwKyN8QnQv+102bdbGSNl3gr1ah8PVVaGTThsy2dWxIF2rs AofTzvao3wyVvTSn/1beP00Uw223vjABWRtHmn3g1IbwIpeB8+HSq5wIdY6Ic9mOQffu4MbWlsWa L7ZU9SWVGQMmavfsH4VOwgpYersEfQqijl8sLrkrE+Z2nCEpiDDQXCBXxtil/5k8PlG0Tii6Tyjh Wih0BIMSJlmBtgk3yn4jWPS8Jovk+5kvi4TZO6P/jBRIQv5M2FRjkCaaaz9Zs7tyCtkqiQsKpS84 V3hRu2mwStz0KoXnqaC4hr7Mbr3jJgzyJi75tu5GT9R2/pzz+WI2h67SAsA8luA3ewsqNmVuZHN0 cmVhbQplbmRvYmoKMTggMCBvYmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDE5IDAgUgovUmVz b3VyY2VzIDE3IDAgUgovTWVkaWFCb3ggWzAgMCA3OTEuOTk5NCA2MTEuOTk5Nl0KL1BhcmVudCAx NiAwIFIKPj4gZW5kb2JqCjE3IDAgb2JqIDw8Ci9Gb250IDw8IC9GMzggMjIgMCBSIC9GMTQgMjUg MCBSIC9GMjIgMjggMCBSIC9GMTEgMzEgMCBSIC9GMzcgMTUgMCBSID4+Ci9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdCj4+IGVuZG9iagozNCAwIG9iaiA8PAovTGVuZ3RoIDg1MCAgICAgICAKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja5VZNb9NAEL37V1ic7IO3+/0hhFALlAYugeTW9mAa N7FI7BA7rSL+PDO7dnCEKSocUaR4vZ6deTPz5mk5oUbGFH78uLrbRBfz6OxS2Jgx4pTi8fw+tpZo FXNpiXJCx/PFdfJmd9i29XKXZizJt6syZcldvl7D45BmQpvkfVHht2KXt8UibE1TARuFP5OB5WTR pLfzD2eXTMaOOM01BsuEIdxqHWcSNh1jPt4NZSYYcz4w9isDwNFmmnKbFCEqRBQiWRaVf99BNMDR 4K5M8vBxl8NutYC/ehM+fD06OASTLZqUuw4lGwRmkhPjbBf5Y2dBY02cgeJh0YjUTMQZI9JJ6c22 +y9jrjixzMUDu5cAQetRr2hsHT91i9kCzodgD4aDajIjiLTUwErBEVjgke9jOCggpn1Kk2Ax9GWI 41Z131+Ne1BMs85ilmbKJldpZlly/qs3LgiXR2N2QxUdcWmJVcr8ZZntk1WGiGysYpYD/4wClxDF KjYs2An5Tgs2XyFXOooty4eebQckVb0PhOqod8OE7OhXb150XEszZN+RrxkuysXIhFDfS876NKj4 3WToDttFcecHFdzumyLgqu9D3HZVhMXs6jxjowMpiDXcQVRHrBb8jwPZh72qU26Sx+B+UYcEj0MI WCB21ZZ3eVvWVbB69NXCY1iDr69HGoR81u657flVHJpyWXVgmnrjP7VeyKpljwU70K7GmA50YkE0 nySmfGpQT9EC051QQ4LmFYBZdGA9cq9WzQgeKQm1sp+TBrPAJHRS5e0+MCqDmhZeWcwoXqUJVcb9 i2BNxsaJa5QsaZ7bsM/F+lD2rQAhhvYhJVrkRifPD8dhKYGO0r81g3pBg73w79Gko/2wqO0qb8fy 044oqf5DITyde65BZSx//tyfSGHZnOiMTNogRitsRPlt/7M1XpqOzSk7RbiaTDFe9G4eMX9HYbEU RDjAA4RSzuGl5Vt0fUvjRUTjDxEF0DBIj/BCCZPMxJuIO4V3HNbvrKNZ9OnoL+sdZj89hmuQiSVw FsqKM9YZQSewKp4b7+aXgFLJxFCAbjhXySykh3ntMDGl8OJD8eKTTd6GjXNPTxAgfGAdNqCDwZFP G55TPp1B5hmnBg6LvgQ/AH4XQ6plbmRzdHJlYW0KZW5kb2JqCjMzIDAgb2JqIDw8Ci9UeXBlIC9Q YWdlCi9Db250ZW50cyAzNCAwIFIKL1Jlc291cmNlcyAzMiAwIFIKL01lZGlhQm94IFswIDAgNzkx Ljk5OTQgNjExLjk5OTZdCi9QYXJlbnQgMTYgMCBSCj4+IGVuZG9iagozMiAwIG9iaiA8PAovRm9u dCA8PCAvRjM4IDIyIDAgUiAvRjE0IDI1IDAgUiAvRjIyIDI4IDAgUiAvRjExIDMxIDAgUiAvRjEw IDM3IDAgUiAvRjggNDAgMCBSIC9GMzcgMTUgMCBSID4+Ci9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd Cj4+IGVuZG9iago0MyAwIG9iaiA8PAovTGVuZ3RoIDkzNiAgICAgICAKL0ZpbHRlciAvRmxhdGVE ZWNvZGUKPj4Kc3RyZWFtCnjatVZLb9QwEL7nV+SYHGI8fiSOEIcCrdQKqqKuBBL0kCZpN+puUjbZ VsCfZ/xKd6kr2AOq1HXs8cw337zMCC1ETPGPzat6Hb1dRK9OuIoBSCklixc3MTBGBIUyZkIRWfI8 XjRfk3fLYWz7NON5nnwY8BeSOoWkmtIMkg5XgzkskqOU02SaqvpuTK8WZ69OQMQlKXOWa+VZAYRy JeNM4GYJYJR/o1BYYcZ2hN2KGpmjlCmrVy9abXaDFjlPHvVG1SMGA2a0u5MGyUVy2052cZ1mrEjw C/8/zjrQJ4sSdgwDp6RUwJzpLwFswAiXuXASxnoT0qSQS86d2D0i1oabtm7xwjgOqfbCXFM7tyQj wIvS3fpGJQ2o5kQVQuxDVHvsUS7lkw6wInxXJmOME05BxRnk6LK08fgVcpgSkVM1R8OQvKnQgb4Z 1vazH4x/DW4acrOusQdLLTfaOFTPoQLlmAzeXwg4K3Q8vLNvUpkn5yGMOVG89BlTL01YahNma3u4 0b/M5ALGoetvLb6ufw6qKInMmTogCHN4Ax6WBMlj/yWiL+t4ja5jvQZUAcdocvFc116xMlkSAA6Y HZIwPLPClL9UrIVT+HnpClQzHwBJdX472fNwdQkAz33nMmdapnMk+y2u19qIq+udhmCjjOmo25LN yNap6HrXHZatk32wN1e6memu8CNEBBakBMCuBYIALf6Zh8UO4rH7uZeFfM8fXyGQLP3iXkOq3bnn oNOcbtqVQf1gym8KIeY6ETgCLonKOftrm/WIjxxBWrPrtkiuI7au3Om4rW1ZGRjNXETz1Yc5/tVt KANA6naykwMZy7GuQ3nKhC8bFgCvsH0xLzBtOm18NYZaHeQ4zhjAoa3OxHCm300XT8SgOe36pzhW SJpvOnfBmsJWh/3u8MgszNAarN3rauxqa7EetvPsazdrQ7xJpu2mDRGBla/ygxv+5coUk5mdBkEz aDiP2lr/PJ1HBwNFNp6OpRXTze8a97aT/bYZ1t47gq0rpkx2uYUXR5jHeaBDHyv/kDC5O/nhNLsz 9Ks/A1ubiEbHiwjMAwpigeOzxCCibYkDDF9U36OvVzRuIhqfRZQwxWX8iB/Y8QQU8TpipdQPMPA7 q+gy+jTry7zC7EmjfaMVdgZyMw2dkCKKKZtBp8eLEwQqRVJQZKtgTCaXreF9azqGPpTJhX6dte0m O31vN45Mqxm7WxtI7KltP1lFpp7x94JdXJ5eYIXSAi8LT8FvSsxo+GVuZHN0cmVhbQplbmRvYmoK NDIgMCBvYmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDQzIDAgUgovUmVzb3VyY2VzIDQxIDAg UgovTWVkaWFCb3ggWzAgMCA3OTEuOTk5NCA2MTEuOTk5Nl0KL1BhcmVudCAxNiAwIFIKPj4gZW5k b2JqCjQxIDAgb2JqIDw8Ci9Gb250IDw8IC9GMzggMjIgMCBSIC9GMTQgMjUgMCBSIC9GMjIgMjgg MCBSIC9GMTEgMzEgMCBSIC9GOCA0MCAwIFIgL0YzNyAxNSAwIFIgPj4KL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0KPj4gZW5kb2JqCjQ2IDAgb2JqIDw8Ci9MZW5ndGggMTA5MiAgICAgIAovRmlsdGVy IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqtVktv2zgQvvtX6LbSQSyfIllgD2k3QdND14sY2AJt D27M2EJsySsrcZv98zt86WELTbMofBBNjWY+fvPNDCnCkicYfrRb3e5mbxazV1dMJYQgLQRNFncJ EQQJKlVCuUJCsyJZrD6l86bOckbS+g4eRRGeMv07s5sZw2lzn31ZvH91RXiikS5oYZ3lBGNECs6T nBaIkoI5b58xkd6a0oF1WGFnc73KSGqynKRLWLzOcs5FulveZ1TZbcZ4ujaVaezbtqzWdoult/GD alVaB8vWHLyxc/Vtn+VU+nUFrw92UcLi0S6MxwR89JgY4qrQcBCBNJHCQft3AjvBiBdYBfCX35a7 /dYE1HsLxOJu2tJi23qse7dlyl3EvDYTFGKIzZFQmgTqMAtW5JQ6GaLPwSHTqTHgs4EDq/Q6y6VK V/7D0fE40pyF736fcAznEqQgweImy4VK32W5IunFuTfKEOWdMfmMBZ5wqZASImL9eO5FI8yECO/B B5kSli6QEMAJnBRJsD8h51xXMeCbum3r3QQsJmzcyEU16YfhLsVfy/bg8wi1cO6NalQQQn8uI6Mo gIPrIpbB7uHQegF/jdK1f54MFORkvUlEWWSliKyQiTgSSa4iKx9cSZiVP1Fb+yhtA3i/+/Wyq5Jm qNVh4hTUCI380AAPJwXSEmoKDEBsijCoqYIIPqQZNkdWlOsu/zhoSA5MoJfQjiIyQT8cTmPgYRDq 41TVUsREwYOjx+X2ITadw5iJtWkjDW7/0dVxuZqSt0ScUvZzmR9nj4JqhBD/Q9WLDfgvQ6srbWtz nbAZ9lDX7GI7PIRtqtPGmW5CA617vQHY7+dZJlDlTCv+XJ65zzP7cZ7V83mWJ3keC15Ch8bQwnJK QNBg/NyAGVEWymlv8/70tDWeBNeRQ+ExV3jdzGnLcZHA07PX++pHjGnyKJHzoaJeOlT+bDemOZY+ jSH2xvTV6YC0y5h7Pymb07no/zsn9baffGN3J3zU1e3AallFBjZRXi69blQNdGvHcxQhzGHvebes +p5yStVhgqs8kvBCtsYVEcr5GHMVALy9gPV88fbdRTDwYzpg3XRz+yTlK7Pf1r48OkPT19tUZTPA bhsSUYgwwl+m0niM2nK3DUGPFgCgkC7q/WGw67BswzXjuDHVC9XiNWaD/dbGu0ruoykbAXLW3MHb h+0vEzdCyF6WurbTq7be7X2bKg91dTKfNlGSjzCV1uF0D12va36hnj7UbRyKD32xH8t2M+wSdVuZ 1sl4drmYEXfPJgm3HZPRhMClRWt78f5n9ukLTlYznLyfYUQVlMwR/sBlmROZ7GZUC3tPJ3FnO7uZ /dX5y6PDvPfor/IyzljbX4MR3Leoov5Sfbm4AriCpxIDQ5JSkd4YR7M9lBO+EDC04EJvoCSv//Ab F47PQ7mOutiZqvWOyso/53R+cw3TjmIJH4tIwX8yC+w/ZW5kc3RyZWFtCmVuZG9iago0NSAwIG9i aiA8PAovVHlwZSAvUGFnZQovQ29udGVudHMgNDYgMCBSCi9SZXNvdXJjZXMgNDQgMCBSCi9NZWRp YUJveCBbMCAwIDc5MS45OTk0IDYxMS45OTk2XQovUGFyZW50IDE2IDAgUgo+PiBlbmRvYmoKNDQg MCBvYmogPDwKL0ZvbnQgPDwgL0YzOCAyMiAwIFIgL0YxNCAyNSAwIFIgL0YyMiAyOCAwIFIgL0Yx MSAzMSAwIFIgL0Y4IDQwIDAgUiAvRjEwIDM3IDAgUiAvRjEzIDQ5IDAgUiAvRjcgNTIgMCBSIC9G MzcgMTUgMCBSID4+Ci9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iago1NSAwIG9iaiA8 PAovTGVuZ3RoIDc1OCAgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjarVVN b9swDL37V/hWB5hVffhDPrZYC6TAhgwN0A1dD6njNlodO4vddtn+/EjRip3N2DqsyCEyJZHvkY+U ZDyNfA4/uV/la+907h2fK+0LwbI4lv78zheJZJFUqS8jzeJMJf58eR1MqyczEUG7aCehCHBZV83k Zn5xfC4iP2NZIhO8HQpwxROu/DACayaEvf6Zi5ROSzk4bVcpQMEzVyt0rpQKzB39LyBMRcsCw34z TWuqe7JsJqHUQWE3tv355qHBjyjYTWC7fqSdtibjl9r0Pq/fTXl6Q7AgBz0sxSKdaOCSsEzHxODH CHzBWZRw3eH/NNHRPmCDsNoFYthi3ii8BeiW9lxemqLqdp9Nu+q5pcS52IZmSdaPI/nmgDJmEmyU Zq7+lubTxx7PQY5yDGdTftTVYdG2+G03HjpTBQa4lkL9YVWQn8ZUeXHg8mhb0IWqbgeE5S9l+z33 oeQov/hfsz9f9XC2RUNhQKPmFuxlt+GCd3oxIOrWImnIQMQONKOC274Yeb22NTkoYVesIaP/LNHl BjGbtpMKMjPd+vsw7XXXJ8AXgxMQy9mQA6SzozO9uBzJkeZViukUWldkTCdKvrh137si52VBKpKZ a8pVjYp4pv12ZbpUr4py07xa751gDFBr/oCL4UzIIb6VQlO4dDoIh1IUQehG2/IPVVTZi8t4UZuq C2Wn5kCh9dM+ammHxG6sHJ23UERM8PTFca+wwNi4ewUNpawdBjsJXQMsBxN0bEC9XqOelE39ZkQa S3xTxsbSdrdp6/stQtusjJtH+FmWO7qAPW6qjgNJYHfIfLzWttDe2dwT9kEUfqSYykD4QCnOMnwh v3rXN9xfety/8DiTGgg/wwdnIhKpv/ZkFuODKpyl9C69D3t/oXMY9h7pzU39CLImFCbIHdJMS01d Nz2bnwPyOApSDlBTKePgsrDMcX7b6RrHwWyiOM6zcPqWDCd2EjTmHv9wVKzpeQFHpqL/mZxdTmeQ D57C5cSl4CelRO50ZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iaiA8PAovVHlwZSAvUGFnZQovQ29u dGVudHMgNTUgMCBSCi9SZXNvdXJjZXMgNTMgMCBSCi9NZWRpYUJveCBbMCAwIDc5MS45OTk0IDYx MS45OTk2XQovUGFyZW50IDE2IDAgUgo+PiBlbmRvYmoKNTMgMCBvYmogPDwKL0ZvbnQgPDwgL0Yz OCAyMiAwIFIgL0YxNCAyNSAwIFIgL0YyMiAyOCAwIFIgL0YzNyAxNSAwIFIgPj4KL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjU4IDAgb2JqIDw8Ci9MZW5ndGggNjcwICAgICAgIAov RmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNq1Vctu2zAQvOsrdJSAiOFLDx77sAHn5MIC ekhzUGXZJiJRsUQnCPrzXZKi7TYqigAtDFhLesWdnRmuKcI5DzF86Dmqu+BjGdwuWRESgkSa0rDc QShQlsEe5QVKBcvCcnsffWqUHqo2TliWR4uYRGqIExL1LYRtB1+NWSptErJoYxbN8NwM8UN5d7sk PBRIZDQzBZKsQAxjHiYcNgUhtsA3THKXTOlV8hRhm/M1prkpxBiLDtWzjXhUmQeNalvToDSQ3E+j wWD2JxzQ1eVohniRiTAhGRJF6lD8mIFAMOIZLiYMd71UUkGJvSvxFCcOlGnYQat7patajy5BH5o3 YGzai9SHqRc5uuDp9N2Al7V74zGmRdS8zmBPPKh3ot84UWyx56qVWyhX6Wa89AIFfcJoFe4s5gMk 9ob+l/+ERo623MlbaZwRd9ASbMLtwqisJ2YvTFbuYT2gtn03o1ECTc+YkjIkCGbQgkBFxuhfTZlP TZSGGjnB7Sqn2e/aW7Rgike37JWVWTV/suW7qVw4a6mJzJ17KqvaGcEJ8Cgt60rL3md65znph53X eYCgs4xtb1zKq+msP00nN7be9hfa2167oN8ZwAAtIRwRnFuIx7O25mx5UZlF2jptig/Nlf2uhsg/ sdxqN9PMwZDjx8lpvL6kb2kj0Y0X9zz2Zs7sVfvqor3N8cyoqbvjqRnszQ4WZUDsPCYhZ4gJ8B70 lAphBvQxuH/A4TbA4V2AES1YGr7AAiPCSR52ARWpmefE77TBJvhyPi/xByaXE93Iz0MOtBFmGPJJ BSpo4Yy/WpRLwJnyKMeAPqc0hdta+xs6mCbSNFrHDJt5kaw+u40PVrRR7h0tYKHG/ifAQVK555qu N6s12A3n8HLuKfgJ/haZZGVuZHN0cmVhbQplbmRvYmoKNTcgMCBvYmogPDwKL1R5cGUgL1BhZ2UK L0NvbnRlbnRzIDU4IDAgUgovUmVzb3VyY2VzIDU2IDAgUgovTWVkaWFCb3ggWzAgMCA3OTEuOTk5 NCA2MTEuOTk5Nl0KL1BhcmVudCA1OSAwIFIKPj4gZW5kb2JqCjU2IDAgb2JqIDw8Ci9Gb250IDw8 IC9GMzggMjIgMCBSIC9GMTQgMjUgMCBSIC9GMjIgMjggMCBSIC9GMzcgMTUgMCBSID4+Ci9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iago1MSAwIG9iaiA8PAovTGVuZ3RoMSA3MzUKL0xl bmd0aDIgMTA1MwovTGVuZ3RoMyA1MzIKL0xlbmd0aCAxNTkxICAgICAgCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp42u1SazxUaRzObsWe7FB0L14kt2JmzCWj22BM1ESTQqkcMwdnOs4Z 4wwzKrmMS1tZFVupfmqyWZdUtF3ERgoliW66UFLaVitUKpXdQ9vub/Vx99P+9j1f3v//ed7nfc7z /i3NvJfO5EuJIMSdwMmZDHsGD7iKxFzAsKdDlpauCgQmUQJ3g0mEBxhOTgzAV4YAJh0wODxHJx6T AVkCV0KuVqAhoSSwdrUZIHEBPwxRoBIYByKYDEXCKA0JjIGlhARFSLU94GMYEA+ciABiJAJRRCJS e4jBAFJUQoIgJATFIYcBPx54MAG4H9tSpfwTFIkoIihTwJoyaQMoi1ICx9RAigRDDosJ6i6EcvJv mBoq7q7EsMVw2IA8ldFnKByGYuo/cCJMriQRBRARUkSBD6X6Ih+tiRApqgwbinqQMIZK+HgIhgD6 xxYa4Y6qEKk3SkpCQTCMRSCDfQSXDjVBxTZowcF34TIvvqfd4GsOQt4wipM+avmfogPcwZrxV01l o0BVYCXdnk5nUETq+7RbNeQqAS4hpChOjQObA2CFAlZD1FxQFRusYwAUlyIqgKgovw72OEFSRwAV yQYQTCiggcdkOQEHAkcGmtDn/+DiQqjWzWRywUwmm1JlMJmAy6Zv+BtRolQoEJwcHA8qiU91MErl hiAqRALdvklInDWynSeScmMEB6/mjbDVcQk5mba4uPxa2aiEpm062KFLC8NtW4r8+vIzjWjtI9pN o95PjvimdP2SOvfnceFpu270t0cGtmdGn57s15MpUj+Wm79O6DA4c+L6y2dsHa/GltrcdP/sC/u6 qjoOeFu7+TzRvWc2rGJl5PGKPRoO1889E1uWnFg03dFMbLgrPDeFldwcZZi+fXhzfUKMLFnvlN3d bqJUOabvoN7+Hf0Br05dOpP1HqvsflrI7GF1BPZvaPPIOFbwm9glVaufev1DRNuOgI7rNNpheXlK tMBk8qQaYWELf9vlu5th1pqr8g/08y+UTfytzQKhjXZJce/UwvUp8bNc4j/cNLT9ubO/RSr0lfVN MLXKjh+Xe+kWfbkx+khVlNRjYd1TqHk+Yc6j0XvnW4VrPfIq+nzYKGTdcJxMMgysGfb1vNazAqPZ b4TahV4a6aHZv+g80+SZfxi2mtTE6LisDU3LmLSh4RW0hpnY+tav27S6i/aQ6Fwv2Z16gLn5omaK b81X7o3n3sexgjwOSZ+909Ne0fXmXMlhZ10ySSvvTao8Y9XZJ7ix4HWZ7qJ2WpDMK6Eq6ylv6TQj norjQE/dejm2Wd+jlVt3sUCvpG17/ENZtGjL2D0ZPVZlWm3ckdw7HS9MvV1ji/TGaEfXZ3WMtj+X Oa+4bG5cbFaVDSs5R7C6+JS68XiZe7rdsWmzvpsuNK/1N8bmIWX+p2XkMbuiTCOfI+M9mGb6+MR+ v4WTjctpZOCm2mMxoZpV6+buXzKi8xHchm6sTwj4Kcy9epmFMDUylKmc0nsbr5xVdtj3hrP4Fcug IOuBQNbA0Il3YRUFFejnZzsHddxxUq8sxPp3Lud557V2Z6QkO/WEBCblxpkEZHrGjHrhNddy+Sb6 4TcGo5oLnCWe10tk/gpaNrmdU2+gzs8Ox1gGu5ZsJEbezo9peklUJG1eM4ejuh+eFzWj+3Wz+Yy1 3ftSu+pP5hBVDdA1i4pIIw/dfO4aUF8XHH00/WF1rZn6vLWjzcVH7CfZJsNtr5bs9y9+E2QBxxaL 5l1pchRaRpXUCW1FbW295g7RlnYq/SQ3lb/v3tDH07e1ur3hVFQ5TDxg/y78S9drzCBT9bL+AK7u osdvq/O7tXzdxInZt7bxoCb4QZvvjwYn6U98yxslae1ffFsAd9DSjcNlNfNlOPuePKciT7xg+PvU XQGVgZ52D36wCKjJKCqefbIzsd9rRtP4ksrG6GabVRCtlLZVs1tcmsNcdQ7OSayzGFHKja6adOFx UR1DWt/lWOvDOTVsZET2Lcmv060YdPk0YfWKqEVRu99tmeujbRONN6xXJeQeFSdW36e/MBascLP+ nrNvezlrq+Cs57PV4+Cp40xWd41NMxD18vzuWTh3pvDXAVHZaKigoWWO0mAv/R8u6H+B/4SABENg BUmEwYq10O/X7FuDZW5kc3RyZWFtCmVuZG9iago1MiAwIG9iaiA8PAovVHlwZSAvRm9udAovU3Vi dHlwZSAvVHlwZTEKL0VuY29kaW5nIDYwIDAgUgovRmlyc3RDaGFyIDQ5Ci9MYXN0Q2hhciA0OQov V2lkdGhzIDYxIDAgUgovQmFzZUZvbnQgL1dLVU9BSitDTVI3Ci9Gb250RGVzY3JpcHRvciA1MCAw IFIKPj4gZW5kb2JqCjUwIDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNj ZW50IC0xOTQKL0ZvbnROYW1lIC9XS1VPQUorQ01SNwovSXRhbGljQW5nbGUgMAovU3RlbVYgNzkK L1hIZWlnaHQgNDMxCi9Gb250QkJveCBbLTI3IC0yNTAgMTEyMiA3NTBdCi9GbGFncyA0Ci9DaGFy U2V0ICgvb25lKQovRm9udEZpbGUgNTEgMCBSCj4+IGVuZG9iago2MSAwIG9iagpbNTY5IF0KZW5k b2JqCjYwIDAgb2JqIDw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWyAwIC8ubm90ZGVm IDQ5L29uZSA1MC8ubm90ZGVmXQo+PiBlbmRvYmoKNDggMCBvYmogPDwKL0xlbmd0aDEgNzQ1Ci9M ZW5ndGgyIDU4MQovTGVuZ3RoMyA1MzIKL0xlbmd0aCAxMTEzICAgICAgCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp42lNVDAjWdUzJT0p1y88r0TXUM7RScPYNjjRXMNQz4FJVdS5KTSzJ zM9zSSxJtVIwtLQ0VHAsTVcwNFUwMLcyMrQyNeJSVXDOL6gsykzPKFHQcNYEKTJXcMxNLcpMTsxT 8E0syUjNBZqRnJijEJyfnJlaUqmn4JiToxAE0lGsEJRanFpUlpqix2VoqJCSmVyikJSanpnHpQ9y kGdeWr6COUQ4pbQAJlWWWlQMdJSCBtCRmgpAJ6bk5+VUKqSkpnHp++UD7UoFuoQajkI33K00J8cv MRdkPCiQMKQTczNzKqEK8nMLSktSixR881NSi/LQlYanQtzmm5qSWZqLLutZkpiTmeyYl56TqqBr aKJnYGwKkcgsdsusSE0JyCxJzlBIS8wpTgWLp+aloDsFGHpgh+g7+0eG+AVrQ2IVLBeQmJlXElJZ kKpggFAM5hsi+MAwKsqsUIg20DMwMAQqBEIYKxbNLte85PyUzLx0BSNTM4XEoqLESi4DoFFGpqYK 1YYKmXkpqRUKqRVAB+vr5eWXALUoAEOmViEtv4gLFKkGCvq5mXmlxSBRLkxfODnlV1TrAlOcrqWp oYKhkamRgrmFUS2KwuTSoqLUvBJwOgGGBYyflgkMv9TUitRkrpvX8pOtW7Kmb2tbWee6+MIqVn3O nyfWvrzJfiBiR93szJTaYNN5gYrpJUteLXy0te+wePZFCa9k66nCRVske/164r4sEl6ztWvBsogJ Dab79W4Ei1c2d03j/aet/srzcGHYjDmtj6St9hc9ntWprHPzi3L9CZ55KS+cohbv+37vGreQVtAk LSUp85sr2O8yiolX3n1+KdBTbn/qyp75jzae7y2KKtCQ9Oz3+v/MYveyjcptxz9rLw64prdI4uom v2dChw7xO5+1/sv7QVsiOlO3Wn3fcU2+93d+6k+9+zqgIOMeNzdz4OM3O544PxPcx+W48MeJOdYH s011TJxX56fFrYnjOaI0982fiIfhqU4+E+eo29UvcthXrTdVanvnRfWk6D3bme0YAgJe6wltPPH0 81p5l+WS4Wt1jtpOrP7LqRzGKBrR9s7swuG7eVWL3s85wnS8/mPIvIRZhfKHDwk+8+tXs01YWjdf 2/2xB/f0rvXJbV2vVG/Zhgi7VZdd+qDfMP1Si9yttPJiqazzb7hXf2TM4pitq/Klem7atvKO7Amr KqpupG793vfEZJX79g0fVbycRFXl7xwr+Mu4Uknt0bH0QyZOMy4whkffr9CdNrc575TgI83jC+s0 vvPPFle3/+Tsqruila2r+3RgarC/5bTTN24Ws9+OtE3Ikaz6ozovU0ZFP08uVbR0W6vW2pCwStZn X53uLOSsz13ke1JQf3/Nk26LyuCKau3TLRLF6y7dX2FseXmeyJe7VoERruprrCYn8wrJaT04MXeO vf6vsnLnjerZD595sAgI8F8V+LjCgELANWrAsDAgOSc1sagkPzexKJsLAL0vakFlbmRzdHJlYW0K ZW5kb2JqCjQ5IDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2Rpbmcg NjIgMCBSCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMAovV2lkdGhzIDYzIDAgUgovQmFzZUZvbnQg L0NPWVROUytDTVNZNwovRm9udERlc2NyaXB0b3IgNDcgMCBSCj4+IGVuZG9iago0NyAwIG9iaiA8 PAovQXNjZW50IDc1MAovQ2FwSGVpZ2h0IDY4MwovRGVzY2VudCAtMTk0Ci9Gb250TmFtZSAvQ09Z VE5TK0NNU1k3Ci9JdGFsaWNBbmdsZSAtMTQuMDM1Ci9TdGVtViA5MwovWEhlaWdodCA0MzEKL0Zv bnRCQm94IFstMTUgLTk1MSAxMjUyIDc4Ml0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9taW51cykKL0Zv bnRGaWxlIDQ4IDAgUgo+PiBlbmRvYmoKNjMgMCBvYmoKWzg5MyBdCmVuZG9iago2MiAwIG9iaiA8 PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvbWludXMgMS8ubm90ZGVmXQo+PiBl bmRvYmoKMzkgMCBvYmogPDwKL0xlbmd0aDEgODIyCi9MZW5ndGgyIDE1NjAKL0xlbmd0aDMgNTMy Ci9MZW5ndGggMjE0NiAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNrtUns4 VPsapoOcSS5JRA8/1ezczYw7lcug0LgMtlvpjJllLM3Mmhkz0yAiZEqKKJpi55KaiChipyOl7KSr duowUjQqctnpwpbOwq7znPaf5/x1nrPWetbz+97v/b7vfd7vhzX0DzR3pSFRkCfC4pnjLfCOgEgi 43EAb4HDuWGwWCIXovBghOVO4UGOAO/gQACeUBR6QD9HG2tHGwIGC4gIO54L02N4wIhoPEeyA65M iAtTKSxAovBiICbag0phgECECkO8eAvgymAA8lxFHCBDcRBXANEsMHg8oMFUHoiC6DALYzknyYsV jQC7BZjGZ39NCSBuHCoKGM3LNAaoSBrCYsQDGhSNsfRF0GkQquW/Iev75p58BsOXwpxrP2fUn9IU JsyI/4OAMNl8HsQFJIQGcVnfU0OgBW0kiAbzmd9nvXgUBkx1ZdEZEMAtQHCcJyyEaP4wjxoDoimM OGgeh1i070Wgzs1LsNwS5LvJNch0YafzOX8KzOIFxbO/dZ0jz8f4f8WoO1xYCCJwqL14lIi+X0/b vpvlwaIiNJhFBwQbW0DhcinxGPT2oJENSMQDmEWDhAASooItLVgIDy0BqCdJIBrhYuYWao0DlmwK F2IxoGjeXGoBxf+BLqzvG+wALBEW9C22QYt5O5FvsS1aBnH46EbnkD974uaGCBPNCTZ4gP5QlTic A3CwdUj6NyaVz0UH8+avHGrt1zgaRhcBQUKIinn6GKE6pccWNOyVJHuU3T+raCLvRr+U43vhateV JWlPcuUZFR0+HJO+utDpSrGmqkxRZrBzRi9uf/OugDueY6mcnMJfZ2WCv8nECU16ob+JSfEv2as/ pg2rXW54NDliI+/3sO+2JD+s/EbR+M3hEn8j96Chxb2Gcq0Rgoutx9Nt7UI9xYzgzIy6H6wMyeqF HInIOlO6Uz3/sIL0XlpybKZyo2nPBNLMXzZdpnwyb3brR61DGtRmAyvyC5Pl5CHnkTPlmepqtV/a fqlxOQ7ogVwgU/yHMrnDK61Yc29NUYKux/YH49p3PUQkwZhZU3Oo4Wes7ba+isHtVqbbY8q9n5zC jR8uQ6qy100pJ8y+AUc/OZQ2++TtXtufMrZLLY9Xkv3jVuNwRcOlTbFrtMNviI/fX56AV508Eazr moxZzXbO/5LIdxFvc02qiMPAA+rTsW7GM8l+UUvU2m6u939drF1cr7/Fp42szbXUP+gy8dztYLxF Tf/WcP+uA2QN0sxDUtCiXS3YZVINRIHa50I+fS6wwbU0OXUwNV+YftcmWs9Ly7mkGGOyVyWREryX g9sgq1Y6o+rroaqtJBDILl80Ea+tat54viMxwWn2jN9bh87fmUERdc1txZErCmiLK4vygxmPxpXX joUcj5Fr6HWsSV/ifHOPEdf2oJMbT6rUYVtziOrZqkds53autXQyNPPpls/mlJzeIs5/K5d36nco ZLKfr76pphsUjpTJN1bHaKgV2h19mTqhtNwr4FkEX4FQivtcVs8Pt68fKjCpbF2jdFL32MwnnSJO Y8/kEf+f35yYaNrV0t551OtgZ16WrrZ6AxtKer2mIqwnM2R54nLMZqU4o6GBqetJOqK69ByivIdK f7PW6Bu5wQN3qKJ3M+szhGNicLKf5ZcgrVFN0tcx14iYOJe3cichvCt3yMJUs1P9oN0PrerHXsgp rdHZf/bWuxdWw1gnaRZmU1hFrMZGpSj788qxrQ3W4S1Tqj6RXdPwNaxroZ7pTIF69Yd6TFa9Nb79 YldKtyG1WG7bDk/R6IqWyXTi0K2Xv0fcEG1ct+q8tVGB4/bxoOjrtxuc6xqvzsa+zU2WFXnVeZeO p8IBCmUi1RDVA/evwn8NZWe+llv9PvOxv80vZWHQJM825tPWIBmdYy8OLNkw+8p/fVpN91/kLnva 9Wz6fKFd1tU9sJ0ZEFk2ZGB9CY9o1J1dVJgLpQwHrn84xPQ8TT0V9U7vRxZ2Bb3UayJPnfzUozbv aUf7yxPE/OLFD1abujjV1RJe7c4+Gf06Z7DkWbyVzSOPYxypKAR7LFhLru0FiKNIrAg7WrTMw3L1 blssdj2ibk4cnTq8rHPlswmJ4NZUVyi8X5rlTV8lDgP6i15gtbk/7Tg3cGjlho0qrDFHgSHuS9WW iZ9cmj7/6sFSVbpWu+1Auga/zexkG1SRAi4q1OR9oUuOnp+9J9dP3Pd8k7i6v4TQeEic/ID66qMG h2I7PCRXRJy6vOSi96ypAMy0KZS+7Un7cirjSaLuPihJJV2tVNKjkruRX5CtJTIeIOXw7fV+Tqhd 9wxxIDermZ15E0m5XldqrWPdtfTvNxh3iBdiR/reQpnWxlUEPf8rVLFilYfVHeae7FTD13cYg01+ nsLDBrg8emgYqWMw8lh7REbFTTtMxN4k3cCCdLbxhPTM01jJzT6MD1t6P3taT5pXOVFmL0+YpM8W GK+6C8wTUp4EDn3UGEgKURF9sDj/AKQNr5Rpjy0yWCQWs3/7oBuhNR5yWiJ6v1LpqW614ymce/Gk fkN5pVcvpZX4yX1L6/N7tjjCER1V/Vcco97HBrlJ8Zojks1etTN+ksaiVYTPu/cnYMxIe1w7E8sP EzYQHEMuhd+71HHl2uiS4H2b9S35yUJkWQs5QzdAiAQ0rcuMPjAz+WnUPD2D8qG60jvGN9y7pWbi hmU910ygP6Qou7ZU5N1tH16dmNhcu3a9e8hUiuYbp/uNppbKLiPXTLBw5NFRUGTfGCbs7UifJjIa y4mGY6uUNLO8dlOk9gkpDyc35JgFd2+eGlHFm18PiXd26N09rSIrXrbH6v1xd5WrVS5LfVjTUu3K j9Qshxncf/hg/t/gf6IBlQFRuDyESeHuwPwTMpJl0GVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmog PDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9FbmNvZGluZyA2NCAwIFIKL0ZpcnN0Q2hh ciA0MAovTGFzdENoYXIgNjEKL1dpZHRocyA2NSAwIFIKL0Jhc2VGb250IC9MVE5HQVQrQ01SMTAK L0ZvbnREZXNjcmlwdG9yIDM4IDAgUgo+PiBlbmRvYmoKMzggMCBvYmogPDwKL0FzY2VudCA2OTQK L0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAovRm9udE5hbWUgL0xUTkdBVCtDTVIxMAovSXRh bGljQW5nbGUgMAovU3RlbVYgNjkKL1hIZWlnaHQgNDMxCi9Gb250QkJveCBbLTI1MSAtMjUwIDEw MDkgOTY5XQovRmxhZ3MgNAovQ2hhclNldCAoL3BhcmVubGVmdC9wYXJlbnJpZ2h0L29uZS90d28v ZXF1YWwpCi9Gb250RmlsZSAzOSAwIFIKPj4gZW5kb2JqCjY1IDAgb2JqClszODkgMzg5IDAgMCAw IDAgMCAwIDAgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDc3OCBdCmVuZG9iago2NCAwIG9i aiA8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA0MC9wYXJlbmxl ZnQvcGFyZW5yaWdodCA0Mi8ubm90ZGVmIDQ5L29uZS90d28gNTEvLm5vdGRlZiA2MS9lcXVhbCA2 Mi8ubm90ZGVmXQo+PiBlbmRvYmoKMzYgMCBvYmogPDwKL0xlbmd0aDEgODMzCi9MZW5ndGgyIDIz NjIKL0xlbmd0aDMgNTMyCi9MZW5ndGggMjk1NSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+ PgpzdHJlYW0KeNrtUnk4lP0abhFlyL59kTdLlprN2qiPhiKF7LJVY+Y1DWNmmsYgUl9kLeqQdURk C0XIElKyZKeMJVLZhmmxpEGWM3S+6+v0/XnOX+c67/v+8buf537u333dz6u8x9IGisaR3UBjMokG RcKQeoCRubmpLsA9IhD8yspGVBBDI5BJRzA0UA9AolA6wHFvIqChCSB09bQ1uR+/MmBEpvhRCfhz NEDVSG2dpAugvUAqAYshAeYY2jnQi6uBxRABGzKWANL8YACaSASs1ycuANbgBZBKB3EwfiQSwBGw NMANxBNI/PB1S6YkdzKg+6OM86b82aKD1AtcU4Dqhk01gGsSRyYR/QAc6M4PtyBzbwO5Xv4btn4V N/YmEi0wXuvy60H9rY3xIhD9/kUge1G8aSAVMCfjQCrpV6oD+MObOYgjeHv92jWlYYgELJqEJ4IA FKkFQ2j9qBMuGBN8QZwlgYY9B7hjiBfAjTpIwv3qhBvfhg/4SbSDhbXNvh+L3ehZYggkmq0fBQQQ f5E3MPIvzI2ISvAFnBEwBALJJXLfP0+uv9x1lIQl4wgkPKChrQNgqFSMHz+CK6WhrQ34IwECCQf6 AqAv1zAcRiLTuCMAN5hLgDuZyr++VdQBAO62XtpASIQ2ACf8BZEIAE76CWoAcMpPUAuAU3+CugDc +yfIVaZvwL+HY2hI9vVHAFANbcT6HBLQ1UZc+jca1ptKBUm0jb+PG/Cf2J3A3QkI+oJY/n4mGXsw 2CP+cUhu4NGMzvvb1C7IJmYHt9ZcK0k8CGO/PSj6mlrWYQvunhW5JuJByBOO+3SiAI5z134n8xgd 0OhvA7/WJ9IoKK52N8mG7wuW7XJ6S1Nqw3Mhr5TwiX75UUrZvi8DivPD9JptD80mkbrpMp8ieHJ7 mStzgZ6X2971QxJwimNx/K6pT8xug/as4ZstSx9NyBnk/swmKZekebHVfpnnQ92eg4KJqMhU8629 dNSwqMY9pqIe4yGhyGr4lUFtHCyfpP+0vEDZ4xBocX8xU8CqipwLwTzm2fxc+2Gef6FvN+REhNfl rZs6CBYE+zWGWtPJVpc7YTfv2xdVnWWdGwgOyz+iPV7arjUVNsnT89LXyjzQxHMhXg4dgxV1PSZi HkYaGhzKySpcyezg3TqVmvkadZD9iPRbkSyUtpa1OrL0vWHa+YqsrAa9SPjK/BbUllIwZu5b0Zxf /NZonYqRPPrzyUB5U6hKzmSqfuxFE0kvQUFefQuPZBvXlzM1XWr1orrePczQ0MzrMZtSewbsim6L VFida9JSq4aGXuWri6dsVpSeupiRuOmlf8oBx5HOQhPLchRkZqZKbVChqsDyY0NGg2ZnzEVHluOY tNPiPJ6HcuOMrCUn2mg43+jFxGCs2JH2VSOVpJVDkgGxquEZ1rNrV4jwhWK26fYePt/7pzqWzXeJ O17kzY39FCz+hPWIRHudSpxH08vUAgZE1AlWVyw3awZU2vqyE8yGFLYIPuhvDhKpM6hqQvvMt4fu pKQ2bO+O1KNu/8JRC3umI75/ItmC4W8wFjZ59XgVmacLPRZefOv4hXuqmxG2qBAl8YWYnsd1Ktmf VRBv33pIxBcylKO37d3VoPXNLDXYp80KeyLr2DLlm+NLwVrDWubj613DOkwJpTm3cqdTTKcor5VT +ovZSYbRijfTSlFRbN+vpTkpSd2ZUu90pEztjleDJnyKCWtDIfqHLWWRZNWV4Ug7oQUmNsGos+ae QviCc9+RcLkSWGO9qNor/QnWQdGbh838kqOuh8WHtrWMXmTyXCx2XF5FQqvbhfZes3CtTHBC613D hIK2eu8sU3rYW00MyksEML1Sb/E9oduEROxwJWFgLKOyXNxeo374SX+DHJhkKZDSW36es+u8YEGp irCi6IR/Rb6MTzBsAC2yqQqu31lvO553ZuYfrHQKp36qwJIlYlodhJ5oOrZsUwVpazvFB59mItL9 wlAT48IeTwtSvJtZaQOPg/il+MwmleWCXGC69GdGSVsYU7jCWF5aglvz0YgDRGWXjgii68KzuANf VebOa+/GxhWO6RyvNSK1YoVR2Sv7868aHzDY1wWp85I07sb3cKqe4cPvZfcW1blEIzLEjQeao5fH llLzZ9t179g/vp+qKcnYPPuZuM9wRGJtMFPd2UeKMyhRovDQoTOjd684Y8VNs7N0XCUvnqDTp1M3 pqvFtjd0q+tee4UdKy6FTpW2F1Hu3fjsY3NHd7xWMtbo2hYfE4O5rfqwANeAsmiFItmouy+nEDx3 hR0yIYVxJEM9DT14EHbH7votO526X/hW3y69oZHeGFhbwnDVMhbMZNaXVX96l2qH2pUSkCUHbdGc qddAABWcI87ymig6R99Y7PC4BLJ1OeKF8SiPUlu/fMB0UFPjnY+qDb14sOA7zWm2PVQ3ml3Ttmzz B+vRZFmcw8KNYZdVr72wnBcHFl2HJON6o537xiOS0crsTkgv75jc9zTcl4qJLPXC/akLrM1Ova5N 941lnLWyGAm3WpWDFvNUj7bl8asQC4ZMsm0rskaaCZ8khXYckstpIn86PlBnyregHNFiysPZ+/Ue 1NinTX1+PKJDN35EQgRRKfmbxSY1oaQTzxNT5O+qPIpiSaUbiqvUdhpfq7D7Vqh1mL2glcdm8KVw 4sNd/4hbKBjyP/kWGoN2dQywxUsMbUr8oqEEsSYGw95YJ23n05p9LRVBkRwo5T3s7qSgcmoxOCew kPSxiy720dHbj366v1oxKTzk1AKTT+CAbYv+b+zdrXPX30eOmjIcVNmnLzW1LbMyaPXXg57bJO0M a1BLePkUvxATjiNlv+GxYBnpHC1vTWyMnGlLS1CbSEvjQTPELvcWscBZZ6ZvpCPn+qLSGSWfGQHp CrQJAemTTnm2iucU5SrMPzVY6vUMetR/5eIXrYNjRt1U+dAz1DGZ/gGDTfIXmJ8pk7J+v1s8iXyo 2LrWJaWHGUge1bvvwWtXxEGZT8dMZzd67/6guZJ5cikBTqwcOivxvE50dHqiWsatojUW7NsmMgyz 2AHp2ON/QPKpCYTRLDNeKYxBHX/zWUbp6GW8S1k6/9KHoTzGh6FQ6H570dLA86QMjzOpZs5HXSuv uUv3qfNuE67ZAnMECx9kyFLfVIalNMCrRc+dtoWp12pATCsFLw0gI+T0ij1G0YNLPq/rAlFpTgzZ QDK6vNe/9F1n2gPJf7AKW3qEyq8+uTUYlk2wDeLhyNqVzbxMZFjFvoPMBmNlTUaEXGkq+NwFp7iW kG9OaeJ6UoPGmZZXZwrqemTtg3Ptz37LqmHx8igdLC5gT9+dKoCdHa+C7y3udHeyEFVIcYh6tE0a yaHqCYESKWnse9OIZIgJWiNncJ/03pXGdBy/LelOaKB7l0xI3io1JOLSyZGrpdKWuZJb99TEuJGF bKV1dKg0//6OS9e9hRokPRBnXyvXQQS805l0uolWQK5rz2mGetTk5/0q1GMZ8n5G2gFpzZd3aIs4 Qb6vln3w+NpHjX2SaV3cDXwoaOWrO5GlPSH7u82TZDMBoc4v/RO/N6JuLW1m10DJe/x2+Y4F+Oo/ jK+YzOd9yXQQhZRaG9rzDeVDvu4SuOEetroctLPmsO77nAcNnuJi+0UQmVdPiZYpinkaMZvE1KcG 9DIlBkzruo402q0qo48Nm3cGSjY/pQSWdZBsEIENouk0pDrKGX/0evXn26hXBuQokH+/QFTb7r5q uGdV7/MEaGTlkSo5zJ7TovMIqx5DK+Val9GWMfjDkLkxBzGZ/tve6B5O7cdUOHaxhG66+iFwRvf7 9refyhN3NpUUIV95j39IpjnQGgN2kQ8B6clJZmcLdtApTbmOaxIvOjLxBLXpy8573pv6J7Ush8ff dE6GPgu/TW7fofoM2o9Hxxsgxm5bIp3eD6od7qlRQvyHD///Bf4nBLBEEEOlkb0wVE/+fwIQSxPw ZW5kc3RyZWFtCmVuZG9iagozNyAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEK L0VuY29kaW5nIDY2IDAgUgovRmlyc3RDaGFyIDk4Ci9MYXN0Q2hhciAxMTgKL1dpZHRocyA2NyAw IFIKL0Jhc2VGb250IC9PQVdOUlMrQ01NSTcKL0ZvbnREZXNjcmlwdG9yIDM1IDAgUgo+PiBlbmRv YmoKMzUgMCBvYmogPDwKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAov Rm9udE5hbWUgL09BV05SUytDTU1JNwovSXRhbGljQW5nbGUgLTE0LjA0Ci9TdGVtViA4MQovWEhl aWdodCA0MzEKL0ZvbnRCQm94IFswIC0yNTAgMTE3MSA3NTBdCi9GbGFncyA0Ci9DaGFyU2V0ICgv Yi9pL24vcC9yL3UvdikKL0ZvbnRGaWxlIDM2IDAgUgo+PiBlbmRvYmoKNjcgMCBvYmoKWzUwMiAw IDAgMCAwIDAgMCA0MDQgMCAwIDAgMCA3MDYgMCA1ODkgMCA1MzAgMCAwIDY3NSA1NzEgXQplbmRv YmoKNjYgMCBvYmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbIDAgLy5ub3RkZWYg OTgvYiA5OS8ubm90ZGVmIDEwNS9pIDEwNi8ubm90ZGVmIDExMC9uIDExMS8ubm90ZGVmIDExMi9w IDExMy8ubm90ZGVmIDExNC9yIDExNS8ubm90ZGVmIDExNy91L3YgMTE5Ly5ub3RkZWZdCj4+IGVu ZG9iagozMCAwIG9iaiA8PAovTGVuZ3RoMSAxMDc1Ci9MZW5ndGgyIDU1MzcKL0xlbmd0aDMgNTMy Ci9MZW5ndGggNjI0OCAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNrtk2Vc VH2392lhQEFABAQZpHsYuru7GxxmhpBhBoahW2kuQiSkpEEaJERS6ZSSFFCkpBsEBB4u73Pf+lzn 5fO8Op+z95v/d9X/t9dam4VR14BHDoayhSujkBgefl5+caCClpYaPwh4cwaBACwsCmg4BOOIQipC MHBxIL+YmDBQ3R0BBAsAQSLiQgLiQiIAFqACysUb7WjvgAGyK3D8HSQClHOGox2hECRQC4JxgDvf 1IBCEEADFNQRjvHmBcohEED9vzPcgPpwNzjaAw7jBfDzA2GOUAzQFm7viATw/a1JDWmHAor8ywxz d/m3ywOOdrsRBWT/JZMDeCMShkIivIEwuB2ATxt1cxv8Rsv/D1n/LK7sjkBoQ5z/Lv+rU//ND3F2 RHj/VwTK2cUdA0cDtVAwOBr5z1AT+L/EacFhju7O//SqYSAIR6gc0h4BB/LwC/KCBP9ld3RTdvSC w3QdMVAHoB0E4Qb/ZYcjYf9UctO/Xzr4dJQMVA1Muf5rtL+cuhBHJMbQ2wUOBP2O/sX8v/mmSWhH L6AFiBcE4r8JvHn/fbL6x2VKSCgK5oi0B4KFhIEQNBriDbhZohsSAvryAx2RMLgXEO51o5iPF4nC 3KQAbzrjD7RDoQF/z1VIDMgHRTk7Q/42/7II8wP53BAQN4ffFiEgn9x/SAQM5FP9TQJAPrXfdBOp 8ZtEgXza/yFREJBP9zfd5Bn8pptI0//Qzbrw/dYj9rfC/9DN1gH5YH/gjVr4H3hT1v4PvNHj+Btv ZsCH/ANvclF/4M2HufyBgkA+9B94U8rtDxQG8mH+wBvJ7r/wv6+CvDzKy5dHAAzkAQvdjAYkKHrT J5D//xUIdUej4UjMr9/tZqH+zXaONzsIh3vBoYCZSRRUIuRJSn1YcYBS3kgJPocbXWpRyGBraG2q BO/mggT5J/TbYUP4w4O7oXefOJaSJW9rlPPB7IS+0tTL+fX4GvCFTt/tuU3JkZNmcGsXumlpjdOb 1d1O6pwZuTbDsOzylmt3lun4i0crfqXmOr9ILs12FF7x1OTlYYBT4NDXGeKXMKaVZIBVVpNmEtz4 +5f4gfMtFVQeaqag975l2jHF1QxN+/yY09ztVLHoLC3ciVSpn0QgDi+7xSEAf7oTw4zpKzF1A3FC OuFPxtmpQCxaKcZUU+l3DRpaO4RLoxxiS4ypJGNqT/2TVU3UjE4elOSQQ4sfIKRUCmiw4VXt5m3O 0sgP4ctVek/JnapGwFKJ/C5vk1j0H59dshwwx+AdWV1cLJxeR9O07UJ9GbGoK3BMuETTZTzYuTY5 BkE0+OMRPYxmEIcXaxg5GdUFYtnobuePMot+735oAU3FJoIoJ19HMM2AAeviZ84p2dxa5lxvGnoS LJW8sMTMOpGSi7l7G51t0elga2UFi4XHzYZTXL1lde/zFCnKwvGsehqUlfOYGwhR00vy9xmlKegk 7pHJWS4bAh1iZz6MecVvObT4kQudn9GXigtnjv2UWBlONup5u10kTB+Av/LsgVMs75Yhp6/oDm6r Rtlj7xHRspqePiq2FJihH49eilNpsUZxmLP3vhhRUolY1R4/brZfy5FcQ5ddFjoeWMmuEXjMydHN YtNfto8hi9e9yH3MizaTaW5rR6KRyxVnvh7gZh0bIQlL+6sx6SL9/ALfuMDd/SlB+kgbgDjx4vSS GI2Lkk9ywHXIybSKO/FdpYZBixnkWknqfN9XR7GlZy35d92ZpEzLWaXbaCrff/shq8cDvmtn6AtC mHFFYS+es8De5TqXUbLAKJd75SH27DPUPVoUHWpH1Miedy7RYcoYlsLLmrxkY76A5WnZWmFGjOaP XHGkAataPYITC2ce78dhMvXyMTo4c1xVpC47FiYzl6NrfpJzLvVl9Nw9iKJ/O2roc5OAlp3WtYVB 0uP7dh5t4+iPZtPbB0VbQvj8H+ptzofntmPHu5AMjaQC5NdRLm5OHJeCURm4jzfeeieWtlbi9lJU DhxSXcTdYn9gZRaSbhavnwfGkbUQVI7gz29bn7fUWFppoSwN0ZDDYlqStMa+Z1DUcuhpLZsRt1BE MnSYfrh+fuDsFCtFw3Qe2yxZY2W/Ox15RN89Dn2FP/Y1hBBXexXflWTfJUz3lJl1/tnMdEgYv0tX Du2oegbJacD8Y1qaDPb8Y1UAiasgTDDT8XndemRnfDLxdzVJIe07zbiOdiyGixDiOvUs642qhx+a +9jwWbiqcy8VvPOu70CYnOUjnrDY45yWCHBhZEftA3VYNFP1bBuNV1YXdRVk/LUXUHeR67UiwNBV u9pqSmNi9Chfuiiu8K5B2ZXQevMZneNPsgMh5B3LjkOCyVFeSOBG8fy4yM+n8Xu073IeqqXuc+J9 wy3ve6EltxL8SMEGt8tyzwjrIr7iwgMgK6tgfPzSTtnu+McnpQQVq7+A/lzAaqdjQDNXxslBzEeD yLzSmq9X7/sacMnxAgRpEDTjr3MX8z1xaFOaFKakifjM018VbJeSSMHnqe21Vt9YXlKarQVlK88o h737eKCkg2DG62W6/osz7dOUMkhJJ4Bn9pu8/ao10y6ppqvDkFD5UzWghTRcxIy8rL1ZKoJq6E3B vrlalsp6pvmagDb20JPcL9y0twovpSbD/QpsylwkMsjVe+PI7YKjIwSl49EqeStUGQc/8Ugtfvjq m1yxsk8ExXWmeu6ZW37Am6FPqEh9U9uu127nZAn+yv2IpY6x4U6ciudtzYrhVrsPFakq3nxnk1Ou JctB418KYNJ1pAZchkP03mtPXSQ3aKZ9MyqQRvYFjRN9Ce6PNfqHNYZi5qh4tt12uHekaIfvPCUk 2jQjjJyNq0idSO/XSYOWuCwMqb8AyeEFbzQqWzDHmRmkr3IXIeYTEtne8+SKbW28XYF9b8p+mUAA hpQIHl4SlAXDBarepd+X9mMen5ZUw8Pu8mpM1XG7F95mONrKrSHdX/AGaWckdKndol9wsXfVMUvN 0WHUvljXKKlzmXvlIqtqvGX34EvYR/tZlhSNTdPW+2chXeHBqfuCOoDt2arw5VNxFkbvC7LAd68x 8l6j2CtrcX0vs2qKvTTlFA0iFOXoKcZVsB4ZG18qSqtl2B0Vvep6Htt3L/XVLaLME9Pa9GK6S0tc q+FrovtVmx+P7IXm19wmyif0iHBULoJn3NNnaObV8VT5DWQr5aKa0tL5db2GQsGLCYeVXsSUHW+H OxooFbQ6u+aVLDqkDp92FidrL6V7eu7qBaBC35iGFXQyMvE5KjOuxlBoD7b50UTqop8/Ghu1vfSw f6c2iOrXf/nS+t49Qws2Uzecn8z7n+VO/PtgvCbEintDnqeF0+XKMwo8azs29DHqk4/2u74osV2h wwMXTZ9HE0IFvb85vsSmiSehvjNdaztjiOmHWQzfy8BKzskA5h2yCGdwkfm8VrDJRR3ks0YFAr2w 2EU7kGCiYeGTw3XLj4OcYmFzq00l7ZcfngfrXivWTs0nBd7Bkve0AbXzXrOcO3W+nn0FWRk8pd1o ORbdntI689NNA7Y2kTvkc1sUS9JMCN5OiPW7AyC9InEsRZY/5y/SUJsa7gRJ4OVpsjuVMCd8f8B4 UfqmpqhNrOLJhryp5kDrp4kyv7hLan7k1pQJO30X/fhWtu+IYWPnLeIl+7C6d6+tNpu/aNPpFKdV zVM+lj0IQaefdo4ZZEUv48p8VGHlFKk8K/AZWZDIjf14py3HXHPBLX/R7/7ueF3BET5DlG1BXlih Rb91xlqDfkUR1bzEhrCltEyaXvxK7BO5IJvEsltrPnDEGxLz3fOUIN2oBY8SM42QSNZ5gg+JLXk8 j/n9avlalkYWNX0/Zxua7MhN7aF96fxWckYp5iQWrRLLfcXG80h12N508F/VsxMYWhtch30TYneb +BlJSxhfg4fXDGozaSpE2VL1dVam/vVUqn+OxWaI/K1Brso9ifWwuHei48/Ai1xoDOHnM9rRGaJn tefRwfKe3bdC2tm8RgvBtp9najunx+oNu0+xCQt9GNSwiTOlEZ4NrC323vu3ygtluxtd1OLQURjv IeeKD8RZFHFcCs9ZuLXxYpTaniWjSpxjQ3Ualz1wkzUFQtnXj4fuFtH6DDwovZA3CPhyX3cGeiSg sgC59DoUKdNlNJILD8ZtT1f9pJSEd/vUsa7xMJLb0Vdqq8VnfJABr5hqcgC84/MW7ws05y0pfktn 5HKaV39hNaHr5HPTmPgAgCjAuyYkbluE3qGur9OiZhIu88psx0t/csTYNdalJ8YDXkKouNNZpd/V lPelkvUlJXHSiVftIlgBptd5ohjmNjYC4dxerTmpstCvru32bWboG/h8ICy2PIEVbXkvTnmBRFOM uZrt9oMEek3RliaDrFOXO9pi8WPW7E7MipPf+0r6YnD2fKD+VMncX0ZKPPJ3XdHewbDboJok76N1 6Dpe+kHoJxRRiEGtzr6tOP8tBqYIovWtJxpqbk55ZAzl2EkbVHHFchNTIc9M6CdVQq2aUgV75eCS CctlrsM76z+Lpox2sW5bmHWBeu/547LxyyMJBCwreJ/ROxCgRP2WUjXmW1BKEfcukCmvAWEld2sF GnKq4GQZCumbr+NP6rZ0j08W+3ZOOp7FCSyQPA7hDAnDdfDKUjPKKJC6pyA5M5h/LjoXHGXtQfA0 k4AN2R+UH5VW4hTitji9WkRXOaKJz4XA3w7cCRET20rJttK9Qhteeq3u2jdqEZLYQR0MuyZlVwR5 mCvTUkjDfpoNdMrNaneY3qpuigLZgCltrLcujGK4gA3+ScpfG+nye7DYnG9TPLLu8qa3yRYPkSDi +FLUDupbWaVupSTRwFbrtkdwqFF+IlGgbcLoqwuoD11/8p1pfkH6FzGPeM+A87sVnA32OPTLSdWJ +2Qx9ExELCoh+g1Oakfmn3MH2E1fjH7mTl3aGOGLkrNiGEljXVPX8pKVKAps0SI0CI/eJlAaCaqe /ADbxiP4tAN9e1ptu/rgRFkP+dXi0cXaJvazb9SeC6F80rJFsxF98yMD6cMroE9FgfPmZD7dI/F2 xre5V/cAhgThtbXdMWEpdvhh0qMvmFOOHF8wlhh+SzUOVem3QxMfbkhhhm6NlNztOnMkjKguCBMO 2gH4O/wYxCERdavYrvwpPzymKnsgaHteexEXWgJt2U7PPJBirX0odFsoRk1kJpFyXicb9h1bkimz 8j3F/vkzuxOFEFKJ6i0T4NCesXsPNSy+JFtz/Gn0XFGgsJWvqwrZS30fMl4U4240yaqVKB5MY8LN zYezgUTUyHe+TC0ebNf0/Cu3kUfxamT4kggNfttG5reMM32q3kDOJvsQy9PrBbwryZCrDhhXyQh9 AUR7srv8w1jY6wio+PlQ3CIxM57icj1gtsMztamKV6dQ/T2zS2OFtfNQ/zkXiak4xft++0YcSMa6 YT0L+tvnPfeKp3HmqyB4KM4PzTn7yiXhsot6rQlPZvGT01jV0rOfYeoSGWESQUQjOUt7gKe1ZN0q HDur1eprE43FLyANOdsHPTwNuLK4st1ySQfyvllupkQ/pt3gZETya+Do5w+mBhm1d9sYw6SRQxiO wgtDNoO5Xb1nIcXt6rFOmIH3ybrxtqSPnjrIZC3RiNsOW1qPmZsyWtGxWc0pkD+eTZzSvqX4ukY6 pxlgVyZ453AnhRRtxlsIzVl99rlLxpuk1mbIh/nuRXJnNZrCWEumpeuO1TuPH/xqNrJvu4IeYgVo DJH9hII3Fw/WmvMz6zRJDAlEMEdq/pwL0Dsy6/gnFE5nujrGRd15mTKRKGobhItR9sjlJx2GyoOB Y4rlMu1IWSyT59kz8ziPKemIEiKl49ul382nuO6Ux8/698d9e1PYy9xqeKki6tuhVUipqGMLHvzi sKbkdq6Ha1GOtYUo78FmDEq5cqovCmbd4d2bAXG1u5USk5mbrJWIURvbVf3Uq4PHK/dZc13Ed1Hm GQYpmG4kOm/Vy1dFoSP0dasbzxYYS7Km8w/AEjGPcM4DJAxF3XqTXrEWCqVSGktCWo7mD7QZLjl3 ykfOW2udfsjCjB5RWVAAWlY63DsoP8g8yUj0bn2ZZUBIySQCgBrcvpyJBRi4/AS92wLnnVWZ718d 0JNP9a82u9gZa4/U9xzSVsuPB3QXMex1f5Ll1w72llPsszLzejn0NGiNuk8myIRqUsuGEcnCQ8a6 rBOhN1kqy73vUqIr7iFuR5CeLOrhX6Jc5nU9WUOc8nWCIF+1VmhIL8tV1IEStDKF+7MPIvSyNqtP MyHKwzSn5yoOQv5iR3PGHfGwJ+wIvLj+HpyN7L+Kf506xErrkacLmnCpDz1KS1IiF8nOwMAHPPdU ppEi99/wmB4RLvcq6Jx4StVZE6D8As/Wd42ip9+fMUzISqmiR201R9Eu3u4hsqw+7RYFJIfhj1ym gunHv2ZTMtX0436eJaHqAisnM667vGbcZ0zr8UW77F/x3SZVqe25L1zZz5O7jP542jWkgRuV86Hc fyioWSPnNrXAmSEpcjjl/kUws038AH0f3cpDNhoRGOPRYoyJEj533i42g9bmk22uFWLZW9jk+IGf Pm7UEWxrBzz6q5hNsqKkPTR+88zaRgwrHJf4XYsJFemEqgEGV3GWHBpWvBzpKGiork1Bx6kM6nvO IdT/7S1x8qaIgOhskGSJ9tr5mtwd1i3W2qA5sKt/uwxDntG2O47ikDgGzGEcxeRNRnvnI9Asa2df XiPgRDM8tLhYkN5iLUuG9oA6I7FaJrlb23RRTK/FtDvuMxY1Hy2Ya25ooBy3lRNX0OaTOcM9nFCC L9K5nnufoZundvXWy88sVrcnpkg/3ZeOpzCJurv5V8rGxwASYt8LtWBattTNbaunTwwCs9x9oc14 VVZ1h5m44+qLzQ6EsaCvajig+UwIJDhHlUAKEz/NbMOl3FeyEUnw4Zor2cMrwllKbJ69sRugIvwa IFLWto6YVVb0Sr/VHtT7cGv6Rf7glHOiiIc3W7TXXzrgx4UvPWzXxgpTftx38j8v8Hw5WtbVpmb0 bLv0FBcBXpDiUOrSuxeu7Mb/qk6O8UfDdNAko/bUBp/SOq+lRCyMeFpCfxU0nun+pFhxK640fDQJ 4dj0vb6x8PSBziN7igdmF6bXHfKTLMy9BYXS1Gxc3QCYqS3Po0vC4OcTLVv5pP0qFPZZ3NMqnNhX PdGQBVGEHtHovrVMwheV6bkWEW3u+TpMH64173oBhbWZ+HVr0/zxX/5b7Qe762jhnY1dD7BzKfli 3ybvbMZysW9K6LZPJ+ewmb6JZnfbAwWihIwtSV3fGP4yW7DHfN907DEQbbh5mUjljqhBmnvG7yfo YBc92E/KcuBNvnvF4XvMjzcyrTUhyFj9WpmzDt/fT7V/18jEc52oO64UkeXZyoTTrIkBX7ykbuEQ cp1Llpj8yOTgUuuPHSPWFn4nT/RjZaokOqx9MGfQ3CQ/SW+sZW0tNNd3gLNncnkg0/Ghej0Rnu6U BGftEf5dpMF5SV9Q26nR4V3d5t3jwBiKbpMk8gsaZ/kpAsGTsu+C50vurHgtXK29n4NmvgqhlE1q n47R4Pv3kGQV//VG6pvzFQF7Mq114M7rxKHB4+5yIXgnSDogwwN3GIx1q96r+QFyLCEQpLvC1xYs W/MShnzDwcphNvhh8snACiiNJFC5KwCTS7IUpAtucnuhRP6Rv+OExZmUIJ/C4zCtJlhOUTg1G72B MIkv3JitKtXh/rYi3FFDvPC914Sx+ueqEmxxjlzeZV0+UYlOEmbqJm25A86jKzEe6AtfrRZnauT5 TKkdKez/KSI4n+l93UGrTfyLIheQz90nhSkGHXYVxJdJ7kyyPaDF4FKh7+F7t9eT4OKMvBxcbM3s dBcpcAuqk6K3jP6ZX3XURE3ivKuz4CJ9gxu2ws9IrbrBKnrruu1WAoF3AJq5jPfTc/xbVdvkUp6j jMpul5VJhQKny1jOU/tiLRRKIT5Foq4v0nasmmQMjAoTI/1bbD8wX2tUWPu9lXHeo22iIzUe4WbO /FAVru7x0EAkUV/wdCDq6c38RswTGKLLiyCbNOrC3gRzgXlW18Rhu2mY3dZLrFqBoOyo9ZILGde7 01SaJAeI5gDst3QrLmJfuak6OM8oQuda2bcpj7K8lT0DjQkVRTjVDZUI79kwNCBLRMtdl5cQoXEv XvS/RgYzi+e4H0TI2epr/cjwSQy2dPWHjsmfpJak994ukg8RhVp8r66PGDd0qzHpHhW7T5W2etzB iyItS9B57rvFNHHEFEjd5NoSfw9qrf9eZJK2COAz3l9FnR9/vWrJ/piqKrJYfSPAw/cVd+u+jz/y Oh30//gA/rfA/4gCUAQcgsagnCFoJ8D/AQNneKplbmRzdHJlYW0KZW5kb2JqCjMxIDAgb2JqIDw8 Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgNjggMCBSCi9GaXJzdENoYXIg NTkKL0xhc3RDaGFyIDExNwovV2lkdGhzIDY5IDAgUgovQmFzZUZvbnQgL09FU0hTWCtDTU1JMTAK L0ZvbnREZXNjcmlwdG9yIDI5IDAgUgo+PiBlbmRvYmoKMjkgMCBvYmogPDwKL0FzY2VudCA2OTQK L0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAovRm9udE5hbWUgL09FU0hTWCtDTU1JMTAKL0l0 YWxpY0FuZ2xlIC0xNC4wNAovU3RlbVYgNzIKL1hIZWlnaHQgNDMxCi9Gb250QkJveCBbLTMyIC0y NTAgMTA0OCA3NTBdCi9GbGFncyA0Ci9DaGFyU2V0ICgvY29tbWEvc2xhc2gvQS9IL0kvSy9OL1Av Uy9YL2EvYy9kL2UvZy9pL24vby9wL3Ivcy90L3UpCi9Gb250RmlsZSAzMCAwIFIKPj4gZW5kb2Jq CjY5IDAgb2JqClsyNzggMCA1MDAgMCAwIDAgNzUwIDAgMCAwIDAgMCAwIDgzMSA0NDAgMCA4NDkg MCAwIDgwMyAwIDY0MiAwIDAgNjEzIDAgMCAwIDAgODI4IDAgMCAwIDAgMCAwIDAgMCA1MjkgMCA0 MzMgNTIwIDQ2NiAwIDQ3NyAwIDM0NSAwIDAgMCAwIDYwMCA0ODUgNTAzIDAgNDUxIDQ2OSAzNjEg NTcyIF0KZW5kb2JqCjY4IDAgb2JqIDw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWyAw IC8ubm90ZGVmIDU5L2NvbW1hIDYwLy5ub3RkZWYgNjEvc2xhc2ggNjIvLm5vdGRlZiA2NS9BIDY2 Ly5ub3RkZWYgNzIvSC9JIDc0Ly5ub3RkZWYgNzUvSyA3Ni8ubm90ZGVmIDc4L04gNzkvLm5vdGRl ZiA4MC9QIDgxLy5ub3RkZWYgODMvUyA4NC8ubm90ZGVmIDg4L1ggODkvLm5vdGRlZiA5Ny9hIDk4 Ly5ub3RkZWYgOTkvYy9kL2UgMTAyLy5ub3RkZWYgMTAzL2cgMTA0Ly5ub3RkZWYgMTA1L2kgMTA2 Ly5ub3RkZWYgMTEwL24vby9wIDExMy8ubm90ZGVmIDExNC9yL3MvdC91IDExOC8ubm90ZGVmXQo+ PiBlbmRvYmoKMjcgMCBvYmogPDwKL0xlbmd0aDEgMTcwOAovTGVuZ3RoMiA3MTcwCi9MZW5ndGgz IDUzMgovTGVuZ3RoIDgxMjAgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja 7ZdlWBvM1q5xKK5FC8GlQHArroXiLhVCCFISgnuhSLFC8Rb34g7FKVLcirsU90Jx50vfvfdL9/v9 POfXuU74k3vNzHqembVmuMJMr6nDJWMON4Mowm2duHi5ecUAcmo6Orw8AF5uHmxmZjkHCMjJGm4r D3KCiAF4RUV5ATLOlgA+xLiwGD+/GL8ANjNADm7n7mBtaeUEYJNj/z1JGCADgzhYg0G2ADWQkxUE hsgBBkEBOnCwNcTJnRsgA4UCtH+vcARoQxwhDi4Qc25sXl6AuTXYCWAGsbS2xQb+dqRsawEHCP8r bO5s958hF4iDI8IUgA1hkh2AsGgOt4W6A8whFthAdThCC4Jw8n/D1D+TKzpDoeog2O/0f53S/xoH wayh7v+eAYfZOTtBHABqcHOIg+0/pxpA/mVODWJu7Qz756iyEwhqDZaxtYRCADz/Clk7Klq7Qcw1 rZ3AVgALENQR8lccYmv+TxOIg/vLAlBeWV9VWfPxvyv616AmyNrWSdfd7u+0v2f/xbz3jDgfB2s3 gAkPNw8PL2Ii4u8/3178Q0zBFgw3t7ZFtISgEADk4AByx0b0BoIEAZ68AGtbc4gbAOKGcAzktoU7 IZYAEIfyBmABd8D+XVBePgDQwvp37F8oiEAL6N/MLwAA2jvDnSDmZtB/FfPvEdF/j/x3WIAHALQD OUBsoRCLP6K8/47+YzIiOxgOg4HuIwh9K3c7K4jtfUgIsRahAje/D4kAgB4QB/h9AGEGbgv5mxGb BzpCXP7IIijyWwoKv48I8f/eAMTx9+26DyIWytwTQlr2noQBQLl7QiSUvyeEAYW/SRhxqE/vCSGk fE+IPavcEyKn2j0hcqrfEyKnxt8kgjhYzXtCKGjfE0JB554QCrr3hFAwuCeEguE9IRSM/ibE0wI0 cwCBbSBO/1U8Ub77HvjvAf6/F/x3XRFXHXhfU1GEptk9ITTB9/3Gg9iW+R+I8AD5A3935x+IELT8 AxEbtfoDEbX7o5N5EMV7/QciPNn8gQhT0D8Q4Qp2j4jLCrT9AxGu4H8gwpXdH/i7kf5AhCuHP/B3 K/6BCFdOfyDClfMfiHDl8gciXLneI+LRB7r9gQhX7n8gwpXHX/i/XyNZWbibJ5cQL4CLT5AHUQJR gLCg6Jv/mgd2dkDcT6e/XnrEk/YftrBGPIAQiBsEjD09AQc/CXj9qTow31sha6gAnQNZ1rImUr2y ZbQJx38qChma0/vMnmOhwvCyMJEEfx19nc71mtoxtNFLa0Bx39c+Mn78dt3FdD3Ro47a8DBRzX3N juHMf4egoXrseFcQWWNkoS8/1ii7I+WgcydDk01edwNzjh6p1cSlqjUpQEjYUDERqhf0roKFn16b MN4+P1ggaN6VMDYabf67v/frIKzax7O/4I3OxJdZWOkxt8/PyCKIwE2D28HhmFWis2ObVT3D8S0i Tl/Wz6+OowGQ/Mff1mHoCzqfaMplFQg3o+XZDCeSl85s1XKhQV3g7IpbIT5a3XK+sCi92j0w6J0x GTkjf2BJ1pBs7VRyGH4i/9riE0W4Z21bd/ae6syd3jVMch37cLC5tUjM1iL6vMH3nCuwflPzYbHZ dZmuJRYnt/HoU/lhueTHRqd6kWte6QtPqTwENhJ4y7XEVXnIQHbSic9qFceIh2fOQ0cxGX5xNWb0 d1Y1toVjlI1EKc/vauNG1JPY+C0vuRMgVTxkA/5i2MdTqsGmZtdSW/RCE9xjDCNtOoFlyhH5fD0T jfi0E2fkirkH7nT3rqdW3KYsLJ9pyrCvfDigSfDCvO9q9aLv2/prAdk34mq4cqyEbDG+F83T1BrH tGIhUMltIC96G0XQGyiujYuw6aWQGhLGS5qSlD59lz2216lDwz2KczmZOXY/HwhdKWH0my0LfP85 qpJD1h7O5pAedPQgsvuleb3V0XgrObGA5awMTRoX3Mqw3651Rbvd1Z7nEx+1qsZYx8AKusyrhA8O CpEf9tZ/6OcKbbs2hYGTxdzvhmqeSbAdKKsQvWKT+R4azFqoj3UBn0oIfSV9JXErlt5lDVtdGg5v mdh8FsvrfC1y186RjNtAko/1KSy+eQ1VI/gpAV/dQsUNQ8RpH05ImUIhCgqu38qJPaxTGsT7Ls3I a9nMIamDnu9YlKFu+X0NFU9R0AOwAqiCi6T98habuF2B0prBhgFJpDh8JgFbnbNYZ3a7Oj7kfROP IqN61XYkcdAGTRXxx3ZeEbHaVxTBQMhXoWgpKMHE5eLiDmW2KKCyVbR5opxA5Qm/X19YRww08oFJ LUmGUiA7w4tn5uQJggrv/ehRe5p/0EGRdpHrtwoHRvo+jSp5cj1D5q72XOpIEhrwi5ypSoZlVuSr 5owOUbrpzMaopxZiB9m3HoloaIaev0hE52AC+yuRlE6Ai1amT05a3u0eU79n0VbHdeXN67bWPwv9 Uf4uV9GDZzk4vGQhKrNeiElZsi4yZWL1hWySj2ChRCjTnj+1950QW9fPxhtBFBH8o1M371lY9fGx y1bIS6cXL/kJaZSUhrWRKraNTb1xXkr34mRF9NTZ5zMnv65et8s4pBr0sJFGEsTs2FE4DeKBsXKn Nj/3oAhyyp+8cW4YYR1s4HFoZXcrly0ZUqxJqamT1iy+HEOVQb392GiZEXOV8bYjy7IGrcFCjDes QyrK+CscTWRydCvEGm29sS3mocV8UQsSzqEYn8gj/8POblM1ddPMbz4T7/MS+WgNuiNP8eoqKptz e5c+KBW/Y1xKHcOz+Ipy3lIMnlh8Uiyk8tARP7ZkOGxNhGWQ/qFEY0x+I7tEFiONxVfIS5cKkXyg ecDb6L4+sa8bJKh5S9fbdOhdqKUMn7HB34MMrPJYkvcZtHsbbR83bR1Wp/UCZlbNXonFYqdtuhwk yMq4PBvPwqOQ5X8gtlV7/SGe+7b9XOfhm5lexf0ZOP8omF7em7owbPUIDe8cU/cuk4um9Oe32wJn pKc/wp0zRaOiu+Bu9PUdGeUomY8CX722awr4WWCSLY/SkMSyFRdzCCUsoJhXIFJLgScKAF/mF72O ofav1BH3fFgvKqPsxpqizWM40TZpclQyliVFTQDp9bL3QSVb4ZtVpc+gJZ4LOKMYjayW0GB/v5S8 qa9RESRMxsxNyNi4xrFQo7DLEzQ7AFh85HR+YPtBG3RQN20/MdRdycXLxMMtubcD8lOvSfna9NIh N6E8fbOoFISdXszoff0uEsdzzP51JyNfdqLJBqrqwSmfYYZN9LqK3EZuI8Yb544delmt/KKei1mP 3C7mEOpG3R+ubHrW13XkztYTRXE45m5r3+Rnv7ol01GcCbEXvcYA3nzLLmR48bPuJ0YQ1aCBBbHK W9o5Fg7CSwJU5vH0GxSNT9gN3EaJyX2qJIHhllRhl/K1bCEfdkMB+mqmY3Z0h0N484RfDSVYGjUJ f8gJYXN+0D57Ru2FJLe26QD7ZMyhIup34DI29C0KbcOOVNARLqIt4xXsFP+RFK1eSxPN8LAEB9Up BBnTRCgnXyrbAJc8xyAznampQzawiVPJgc0k6PsKMRGqkM/ooRRQKaZ1p2e6+I2NgRRdJQaP3GsH P0gcKyD5u6E2W+JKaNEMLCxfzQCl9UCb6TybgVH06LrRlYv7VsBZlJN+Zh/aGbuMZkWe4hbTwY7J ywaYzerqXzChM9DiUSj5FlvTThKfqZ6ipmAxqrcYQC3+Ikys/exWM9qOscL0EStsoFiNG3RE1Bae Ue6Z1aoukTgey5VS4l6iBSr5msrgPNZmDtru2rAeJCxOPZ3WQx1JU0rxbd6hPxLh3Fvm1fExW/qF i9Zo+isMk3sCdweLjC2y7MRZTaNb6BTFQyEDumZ/PU8TwRDbumbnuQbP+8bMvHnSkW5r4oumRoNx h8Zi2tj48YWBWgMFfcIK9ayEhjHnnj8sPEV4X7Yy+Qf5YS8ufu8Sspcf275LnNGZwWpq88PnYyVg naDxosD6NOWX2lW/2mvNPalWm2N/LQ1DJT1zPyuHNHwYfQw0PehoJpdcfBs9A4Kw65JxPJ+yHXiH nv6oDMQlXpViHR1bQjJ8C0hmNSf3Pvssnf1uLbq+4NHGNVcZ0sSsv/yrHDsC3hmeJqvHJUiWeLoF HK3pc4UYD9Xq1HwZtc4xLXCC8uSBH4QvupopPyj4b+hCd3o5L64aL8plgXELxSm8AmY+Zwk/FNEI UIZSx7qoiEyJMAi6J6XDCtu+YjlKuw8mtyhgRmzADyJR+cMoD3Slt1SXUiVM8l52kwae2Jo/TOK3 amWd0nG86xSXgmNkYVIaJHo6qzXM7MLz/Z+bdWM7U2QUnH00xRzzC2iDmA4R1s0foxacsrbBmN/q zyVWkmi8pCA9rwzQbJ6bkRmsDPxGh92hBO3itG5CqZEcix5+0X5c9jHtQWdOVdz6smX2hdgv1ne6 5NYrVSGXSuVQeo1d375MVH3vlHg6FZpzgrwdyugU3vxmX0+6+HlVYAntUNw4zZGdZqPZ7ZgG31vD C7zIxxvctg/lSWipkcfWBtWW7AfFgdbf9RzGJNWWAT9wJiy8wV00QQRHdsrNltXDyTfHPLFKh7k8 sZ5D0IrBqjdqbuQ6RAPIBrNLWRpS6okxJ2qocQrB3BbOjgpFUKqRCeNV6hsbOpjI6fBXrRq7ticL xE2a8VEkCaOHsNbeXiiGHB1efwKjCf8X4nPtPM+2AUiVXIf4t/4Cih+8RXnSRrozvcg+EQ+Rd01c ZIOm8KvuwiBer7G6Y+bqteSijKimO+ccLT6jHutxEhZhJmU+F9fqmPHrm1rOGq4teCNYmWseo27k J5W4bC9ouNpUlRa16YfMBNXtAnAUJk4y2NlFrpTab8l+Dugj/3hn8yw26SOOJXyBbjlGjPO8/JQW pd6dWr2B/Yzxy+ADYlbTp3UMn0um8vcLH6sm/sRfs8rn6N4NKUz7mrN9Qw1zNBiwaFF7QIzuQCzj 3DwmUTxK3kqn6Z3y6dPJzKXWWfII2Aqnk/FKRODXlJ4FUdNXbpWetrlfwxgyZsrj/bRMp67q03cm h5Um1WH6xiTqYKd+TdqVqgnVzYNs4obN9506V/Cq0KscVGOW0X2RjHYLr4b1nvHH8RbZUwWsqeGo 0XfRIPtD/Mn3lJjmduSOO3edQV+zUgNKwvrlHx6d4siyfRnz0rpoYWv+fG04G8KRq7VoLErlQpur XYy3/+JwcSvjwNBF/ctougD3Ddb0XPo0odzAyYaTMVC748BOZIHD/vWSSsvFW2K6C1PnIL9+DRbf 0dODLWVCsy3DB6LcLMTfZOPeyQiNGaWOGbE4tMU8+P7pwyMVMJKWDjKK0jKRsYqDqGyHLqfwsyxY FzL32gziv9q6+dqErdnqk0j3zzVPs7bQtHP9zsYVcn/l6Wo+7bvJoqcUxMruKri0Hhk4WK5+m2Li PfwlClZx9l5GPIcuwZnTjZO9TkT/yF46pXggIWWaaGm8y/bKBOdMx4l58HGSwV7HSNdygl4Cp3HM k+gl0Op0wuAkDLinhAFJ5uinuHzgmq//y3+0A4MVxwH4JqpU2eij9fe6TTEvXmcBhUn3dyy3OFOc pci5UGrCwGiTbUzKWZLnzkKyV3FX5COddzJHLy+XXLvNTSGbMctPFHJHAr22oh5E+YoHfDPbGnkt 5pmmGfWgPw5Ln4bBuiDk5FHbuPuui28FdWjAncone2jJsuAGt+JLu+LksVitwggHYbTp/FfKed12 Yx1cNP51AqHigtRzoJImnbXWhqNV3A2t3KZ4pX0V7wjm1rzCyiA0vhA828hmDVoXNeyst/5xvu1f T0DtVUM/47/GzH8Mj8ZFCkiplEsSvthTsluZggORIyn38/O3nlKXvAL20voQyWnVu6Wb8p/IBSeK fzlvDT2JYnAMz2D0L02NePEBRaJD1VhHO0y1WvK9FLm8elAd4Z0h9adEAdqyb2icpBOLT8PpBTC5 uDpIwZJy1W/pt5LeDEto12CIKGZQ69taFtG5wYTKfoLI7kDthxwe/szMRLNWGA9gP4NbHsKawMh3 5TRiHlqOFHFDuFNKN94esVnq6jOgZrpOBvWqM1u5zea6tW5pPoJCJu+0nLkKr0lIn4HvzzGp07N5 MmMnYOhtWnEmZefaW93Yal8dLvQssnaURUIt6p1osqDN64iFHc2zm1g+Hrgqw+4PMRJchbBK/e+O uIoaZg10ob8sc8nQtTMpU+JWexjGklZ26jf69RTMqQO1kmYo0HIqMAtKwbdG4iBpd83EnwUvY+is lm3pEo5tgq6+RD4UvxGlanUnQ832rRh75Tj0hl473Psx98FCDdY63x6pwPtuq0fTqePpVeygZ7SJ CyziG0lXXbXDL+Yoj2KCT2jAUzJkieTBXza91KTcNlIegVzx2fYpdeJNK25vLMoKhI4XfKRohy7M 1IMN7Q3yVECuCRVBHZ0NzszotACRJKYOYn9eDgzBST+xTIN9GOHJvHKgvsDBFUdDdO1K+y/UEtZl FSLu7Tdmb7CLA2oZ2FPy6w65ebZIDh0Fn+5t6o5dv4+rwYNRkjxlIoU9akiMNQkLVTV1UrY2CCa9 ke/Hun22AgtZcW2afYyFNnfdNn8jkgK/ZFBf1Izm96exvnIZ92XDKzaLovlJZy+4RUg8TIFq4PWA Jro7jMCLtWPqsAxwIVkEEtkBny4MNkh72d5ZP/GcNBffqV0QS0kOKVDiedHEbCKKEb8Cytf39NeY VeZjcETe1kJyQd6Qd2YRPdM4RDm0sP/UdfKVit2h/sqbll+/kUnxo0XrDssvWXnvSXzN4Omc4Prt +XIDiQc0GEjvCc5+GlSZKY4PmrYsRC8LRcykqK9V+PULR2RiCKNZsNxRu3gtfJJ/vLHbHvkI10Nc OquUVLHDDO/jt/cH3oktPjc8zirs+Ch4PLeQU2qBQkDxmd4x7fiIrAbRUA+FSck7G8fPYhUBlztz pduBn57IlrSEFZHSFYXN/ex51FyWH7yrym/Ux823v8lrg158Yi8ajGXBI1uqEqb40ftiO+quyOLV uRVtaHPct5NoVaBJ0uFdUV86FbL7Twuntageyyjq7+fV2foRdrQr1K/6Er0xnmxqVFTFNjZZTDtF fSfUUmQvJRWmc51mLlm/XCo+Rv042+EwCZ1Zb0rY05u8u1Pu4UswD0e9Gx8BiOH2Um/POKeaZmi5 h38BTDG1aSV6Ho61vtk2VpgxHISaK7ofgZ8W74EZlElxNmQsZZMDdJc0NprSCB5PMk6/NRYGhK3g oqL1ZthnSRkVKqOD67xoCScuuQqyM9+mT7SsLivwsXUupLgxYEWcE8iOcTtIeDik0v/oasSbjSa/ fSYn4TalsmzaVixRXS4Th+3f46b54Dj4kDU3V+I7pV6x7EOimWWJfs7IviDb20Q1+7RqZMvX4zzF GV1lx8iyclQG+ey4bbmbr/UDIUg8JJTcNdW1ddthLWOBapG6iYdS8bIpLzELxuldQQpyB1ZzMcuo C2g2ukyDHLsfarFayM9JvLx/KZR4cmbEOOQEkZuMYa1Kn0bQROOG5axLLeXY23DyBxQXc+J2VmLx JYtjjhE+j+5oPFD1xbCbDyeuIyoRPMX3vY4bppqkvZZyjg/4zorxQPrMBTl1Olf6clwqbTDO3lcp mNc46ZFrGe4aC3tYXmY9Zmn12NKryraBqYq4Hgu1KqDX8xoZ47VF0v1GUjtjr+IRXMiog9y4Z38v nap4/9pn/rcbD7fJNj/Ilqu02TVT57wYBi7ljBUVR6qmB4zOdbx3iCX6rDpKlADMT0vn3/1s6qf1 fKM92nLBWnrGR0+5IEnalRA25lM45oefBWVhXUEH9G5/zmwMJogV/8TOFK9hlCi8n/mZK9k4052U aoE46Ls7k5OmQBKW7q7TgjFxbzyKNEb7yRMmqoeoiigkhMjqfQE7rGKMgyavopdRGUMhnXmFobp0 E9UcclApaIKzzPWw0VPUGF5Hu+xzAnAD8Erq0kYpI7Pl8bt00shHa4ILBf4UJ877GC7DyON7RgZP Zklbb1qYvxLSSFRyFqP2Rwa/IfarZr3EOGa43N69KeaJZnhyrbegO+P1ucyIKCpNaFUJRSrSSMvl iOutI8kAPhYSM7+6kED8lTdvTGOVlhM0bHzL3azMiSJNIXEfJf5ne38GE2RXiX0m8/QO1yygRi+2 wDuS8nOCRZIyrg16VZKQe7KbEl5YKQ+3VnVDOwAexnJXhB0CQ7em3M+e2b9F+ahbtvSCwz2l9lPf B5Xs1Aafyx3AgUIpxNnCkF/bUbTgS9KCZBJBfn9q+xb1QV9inLCR3klcxrJWbQ17wQ9TPy5+w82S evnMxWnb7vIdVCGio1DkxeF0AMitLDAEbqnWo9eOpR9II5etek2wOgZTzrqJN8fRT5dNzmPKwzF4 DFD2nYNYe2x4oRsTTIfllJIfEZ9QD5JZGHsS+LjkEDmXlOTPANVIzTZFSjmmfrL6EYz8tE/OVDA9 C35VztGrSwIKpArwmdUdOOs7RU58HHs8QYlxIKRI0l4J1GlsVbvCS17WTjzz7q0MSrdajH4bqBr1 CxJN3VZqzIxsRqISbvvG0rM8o0P3DRWIW1rDqMFpah9xG9Elc10HRsjtMR17qlq/AoiFGnhdiyoy 2oqzYjCG672DDm9whJSJIDXWrpji5nqq7HfOtb4GMYVaRFzznBHHbq/auDIJBNas8LGGU09hLXgG TFqSnZDl+TdtAj3wz5QrRxSx2U3XQW9xniyWRqajhvBQot4YJ7D3hGFhcjtZLit1v05Qe1o3VNsc /UXh495J5aEyM0pqKdIFGfVDtpbx3P4jC7KRgaPFduYKU7/RprjgDSfuMHlDG2iwjmSFTMtOZ95k D5XaEmZ/m2eRlGpinQ0Zr3zCNOvSNyXLuEp6gqjgLhum6azvYZKn+iSgSIyfe/4bHyF2+pTvMeZK WqMw0OJdTfdjuYfA52BbMohDjGkalYxsfdli+d0YGiCPIafPyurdYy5vYHiwOnmvcuQabO75vmD+ 2diyn2i62y1mRYV1EnJ51QbcEMmEtkaIim97A+jEBx/xUfQAcLfOfaRDer9Sf0vHGzaCtaOa+4ok bMCoVjQ2Ku04dy8gFeQektBdzW7HWg3R8XnXiSQgj1fAISjT10/IQKt3MmZL4Tc//GwooPmh7wf3 bQqc3XLxgeMN7mBCvLpGcPXMObPzTST+SqS3e+c+Z7vh8LGRWsQ22owifnv9Ha+xu4brgyuJpjOR b8RMrMGMIdB6kXB/1yRco9ftPjVXv94FZZiSres+93L1WZtyPzqDG7pX+TfHnsPLPBqs1sTNSFO/ ozQ54N1l12/ySREJYRIg/aoTygZVKjVKT5ZOw58wsLcxbaTLWazmfvEy7Fo4S7C2E264Zoj5Ka3+ YnFp3TjiR9vCZBZzZCmTGk8+evHnC/qREn4zx18kEIHNQPuDBJRv6yQ/uuRE9C9nK01nMEaWhk2k eOKDZjym544033DuaatOcirbNCW+0TexraawEQXzK+RFHOZ62DSVSuifihnGDr4ECnh4v5Rznob3 eDDh1PIiXUdtrAMMfRopqzUWjJ7z9GQZd6ZQHs0uMJ9rPOPh/1DES8PLz/TcM5H5w0cI4cxnVoCO eaXCnhajfmh37VMbgVBKi3I/AIs8s1HG0pRYJAT3mXb02iLHZ6nvHbfZ4i7lvhQVLtOosk/QMJ83 lLUh+QTTWQ093eRluMvHjyAfSGYG9ZusQQjmXF63m2kMn4vzxoQtlhHcaD+6vDWY/bBZJFncmytO Ha8gE3h9nJNmjUdgnBDRmBgOb4uj3wzs9wtgym2c6OlZMko9eWDE7QN7Lf/dWdI0q2v5uqgg0aS9 ddaw9uwmQjnEPIoutY0ywxWXifEX5kO6QT2p1YTxZ7zQLbUoyEv31ts2FHF1Cqf1UG+PN8LbaxoD t4hfCiHnObV9vmk+kITajXfLSXSiFHOMcuHKJxF98XooOW7hJVMz1f3+5TtAkpbVHwqhrLiw3ryv MaQEc+TAmGQW5+wfLAOnqZV72wRPi18kSDHGPFJLsRjlmZUZ8ZKcv6LjzrV1Pr3cnK+bShPCxPE+ W6UxlbTlCPS7M+hyOhGRatfJvr3j2AFp4H4MOJ6XccDPodY3xHPXzslmizkF25BiUrrurjhRqfdg jTbixGsJfFTrDlV+ZyEbM2ys8ezUPtuPfFNswmhu59R0iAKnQRJ7hHgChdFeEbhrb7SwprzLixNr SGdA17Z8g0eJ/KRW8jQ4ThYpcLP7pjaA+/vTSY+hfhpB//eab1fJRCVtyG+tSm0X3S+d9tWbKkiY hMfSUf2bE4cKE/0g+H60NznRX1jJ2nNmUXHS7jQ4OFw3HxC842YsYPL98ZQJVsrf6Oj8BXWxQya/ o92JaSCKT1p3OqMEJ06k9ULkyKMjTshOQe1tkf56Bj5km6gtQtVxSTCh072Fqv/5pB5fXtn8y3bK jvab5uEiNGnvjFaVrEOPL09FYibQxW+WLxj92eofhV3mj7ZXcRDrDlG14buHlQOkmzuJnsg5D4XE 87lphF3vDMYHlApVg6kmDQ/UwvaGJhbgNybk4NVporkjwznqfvQSisPK2R2drVa9UQmiIsLHTf6v zF5s6YHcLqI9Ql4E6FfPjxMGnp7AFI2k5wlny5Z8GpDW0W+L1y+APotra86In+OnPBmL9FYLp3Jm Wgc1Lk87SX04dUcZp/X3i4+koATnHDg6ka9OdRnE3M0TMkYaMVMXXVCZvhQHHR3nqtNxoUqvvpN+ EPPN1GFafz3+iu77+y4vEfyaBtwedZQLJ2a24I2uwpbkPCXci6GSjzWf2r6SOSitVE+IZ7zl+T/8 YP//BP9PJABDISAHJzgM5GCD/T/L0oFxZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iaiA8PAovVHlw ZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL0VuY29kaW5nIDcwIDAgUgovRmlyc3RDaGFyIDEyCi9M YXN0Q2hhciAxMjIKL1dpZHRocyA3MSAwIFIKL0Jhc2VGb250IC9ESVZMSVArQ01TUzEwCi9Gb250 RGVzY3JpcHRvciAyNiAwIFIKPj4gZW5kb2JqCjI2IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBI ZWlnaHQgNjk0Ci9EZXNjZW50IC0xOTQKL0ZvbnROYW1lIC9ESVZMSVArQ01TUzEwCi9JdGFsaWNB bmdsZSAwCi9TdGVtViA3OAovWEhlaWdodCA0NDQKL0ZvbnRCQm94IFstNjEgLTI1MCA5OTkgNzU5 XQovRmxhZ3MgNAovQ2hhclNldCAoL2ZpL2ZmbC9xdW90ZWRibHJpZ2h0L3F1b3RlcmlnaHQvcGFy ZW5sZWZ0L3BhcmVucmlnaHQvY29tbWEvaHlwaGVuL3BlcmlvZC96ZXJvL29uZS9zZXZlbi9jb2xv bi9xdWVzdGlvbi9BL0IvQy9EL0UvSC9JL0ovTS9OL08vUC9SL1MvVC9XL1gvWS9icmFja2V0bGVm dC9xdW90ZWRibGxlZnQvYnJhY2tldHJpZ2h0L2EvYi9jL2QvZS9mL2cvaC9pL2ovay9sL20vbi9v L3AvcS9yL3MvdC91L3Yvdy94L3kveikKL0ZvbnRGaWxlIDI3IDAgUgo+PiBlbmRvYmoKNzEgMCBv YmoKWzUzNiAwIDAgODE0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAw IDAgMCAwIDI3OCAzODkgMzg5IDAgMCAyNzggMzMzIDI3OCAwIDUwMCA1MDAgMCAwIDAgMCAwIDUw MCAwIDAgMjc4IDAgMCAwIDAgNDcyIDAgNjY3IDY2NyA2MzkgNzIyIDU5NyAwIDAgNzA4IDI3OCA0 NzIgMCAwIDg3NSA3MDggNzM2IDYzOSAwIDY0NiA1NTYgNjgxIDAgMCA5NDQgNjY3IDY2NyAwIDI4 OSA1MDAgMjg5IDAgMCAwIDQ4MSA1MTcgNDQ0IDUxNyA0NDQgMzA2IDUwMCA1MTcgMjM5IDI2NyA0 ODkgMjM5IDc5NCA1MTcgNTAwIDUxNyA1MTcgMzQyIDM4MyAzNjEgNTE3IDQ2MSA2ODMgNDYxIDQ2 MSA0MzUgXQplbmRvYmoKNzAgMCBvYmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBb IDAgLy5ub3RkZWYgMTIvZmkgMTMvLm5vdGRlZiAxNS9mZmwgMTYvLm5vdGRlZiAzNC9xdW90ZWRi bHJpZ2h0IDM1Ly5ub3RkZWYgMzkvcXVvdGVyaWdodC9wYXJlbmxlZnQvcGFyZW5yaWdodCA0Mi8u bm90ZGVmIDQ0L2NvbW1hL2h5cGhlbi9wZXJpb2QgNDcvLm5vdGRlZiA0OC96ZXJvL29uZSA1MC8u bm90ZGVmIDU1L3NldmVuIDU2Ly5ub3RkZWYgNTgvY29sb24gNTkvLm5vdGRlZiA2My9xdWVzdGlv biA2NC8ubm90ZGVmIDY1L0EvQi9DL0QvRSA3MC8ubm90ZGVmIDcyL0gvSS9KIDc1Ly5ub3RkZWYg NzcvTS9OL08vUCA4MS8ubm90ZGVmIDgyL1IvUy9UIDg1Ly5ub3RkZWYgODcvVy9YL1kgOTAvLm5v dGRlZiA5MS9icmFja2V0bGVmdC9xdW90ZWRibGxlZnQvYnJhY2tldHJpZ2h0IDk0Ly5ub3RkZWYg OTcvYS9iL2MvZC9lL2YvZy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveS96IDEy My8ubm90ZGVmXQo+PiBlbmRvYmoKMjQgMCBvYmogPDwKL0xlbmd0aDEgODAwCi9MZW5ndGgyIDg1 NQovTGVuZ3RoMyA1MzIKL0xlbmd0aCAxNDI3ICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp42u1Sa1ATVxSmdiQl4NQxUEAFr1KKCiRZMGQAFUMUxBJAgoAi6JLdwEKyGzcbTHha i4IU8EF9DFqKyksrOgpBLBQKKFDBIkrBqDAtIFJBiwgq9dEuUesUf7a/Ot37Z8/5vnvOd79zbOcH iB0FCBGJehE45QixITcgFInXQ1wAsblMW1shicIURuArYQp1A5CrKwQEqigA8QCX7+bEdePxmbZA SCg0JBYVTYGFwkWTJD4QyFESk8A4EMFUNCqna0hgGRATEgylNGwgkMlA4OQNJQhElSgZhyJsJgQB BJNQIBKNwnAmZ1KRDy4lAP9VGlEp3kBxKKmkRYGFtMhFgJaIELhMAxBUyuT4EXQvlFbyb4iaWtxL JZP5wfLJ8nqX3sFhOSbTvGYQcoWKQkkgIhCUxKdSQ9BX4kQogqnkU1EfCpZhEgEeJUOBI7SEzXXm vQIwpRemRpEAjJJEAyksU6L6PIojU6XQ9umFcAKDNoSIA+xfz1UPBsAYTgVpFCjgvmXrY+htTLtE YmoQxmVzuRBNpM+bv/ApzVbhEgLB8CjgxHMBMEnCGia9QXTEAwkQwHAEVQNUTSvmsHGCoq8A2pok ICVI5uRYIcBR0KMhEAmK046hyCSsR5wBB1bSKUwZS88r+q88vYCcSHoYKKVPvft0T09CneDo5Aoc XV1oKRDkAvh8XtLfiBIVSdIN9dtFG/gmlmK06SiqRiVMXSchcU+NOVix80TyquNXT07nGE00l/6q Y3wfWpl8GEOSxLy8tfOjqIJ7R3u12Q3mse0WayTu+1lkuWWWX2bE2DHWKW1GflHonm28WvYNsbnm 84wDM17a293zadgSfOjIjt45brVkX+4uGwfdmE1Ks0keMui54XjNk55O41mLA/ctXjCbrythdL/3 kbmm++71eaOVKQeblkkeXLnp6xNgrvTKsGuXLjeOHIMf9zPDpXHt7fZrBwR1HYO9Wy2Q5zP9M2vD 1MNW6QvSbB9eFBepxzOS5yR0XVYwzK+lD2UdHU/0N2LWWnle6r7akNrUy9m9zbvGynduc59z9LPZ zfZ+B0yjuD3O084NVFq2xPSvO3sGSvtjkDG7MPlpERx75PyXViuH47cUVy17ss48K4n9acWh9b8V VDUYd1aZQSyPDp1w98TXRn6thhlOIpX28YHK6Owhjvmd+0taO696F/RtkxuYWH6VuDb8PDPLH/Z6 aZhVd6fni0sKKP508ZpUhxefTKy3kI7nH/Yrxfc6dFbJ2qxDl6Z/G/coTsUYycnHXOMbC/Z8lpFQ xDfdxTDN9Yts6LbosLnfNXJbW7I/JGVV+HC96vjqee7CS/UeWsi6uDEjOKXlHJNrdH+WWeKHGGdp Gxk53jI95sK1p4F+8dtlXiVlSXEGserYMysnMg2rJS2UT7BirFzLSgq0zpMudx4JSBveVPrzy6U3 HZU9Fm39BsJqi96dY4Z5c1PTj/Bs8rgscLc4+kfTiJt9QxtLnS+WENR+/Izd0ecObScbNzuHspua SjtTYhwOtS/3CApz2NO9IEqypcQMLRyt7bDOUYhrnhalCnLYL0pb8zdHugie9DdeHqiZOGwg/M6m dYU2iBFuPl/Huh506gfvizua5yfPVbpHzEtfEb8JzuWM4vniW9fjbxkP9mSLQve5c4NYtlokkfV+ 8ZpMe69Hv08AD2P4xoUHP+0tzxwq/MZkXd3Z01fyZzhXMsp01U2c2oqPfWfUVyjSskV85qKQoZmZ igLRQztrmBqydXKoLvfd5DaC5ZzIAgOWdsFLaqflZvre3m23fW/Os42dbcQHWJhVV0irTmN1zDSi VW7QDM+sL1o9x19b11Nmb2bdxa+fHuYd8suoW8vW7q2K3DL70yZJVFoh9x9+zP8L/CcKSGQoTFKE HCZjmX8COY0O0WVuZHN0cmVhbQplbmRvYmoKMjUgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5 cGUgL1R5cGUxCi9FbmNvZGluZyA3MiAwIFIKL0ZpcnN0Q2hhciAxCi9MYXN0Q2hhciAxNQovV2lk dGhzIDczIDAgUgovQmFzZUZvbnQgL1JUWldTUCtDTVNZMTAKL0ZvbnREZXNjcmlwdG9yIDIzIDAg Ugo+PiBlbmRvYmoKMjMgMCBvYmogPDwKL0FzY2VudCA3NTAKL0NhcEhlaWdodCA2ODMKL0Rlc2Nl bnQgLTE5NAovRm9udE5hbWUgL1JUWldTUCtDTVNZMTAKL0l0YWxpY0FuZ2xlIC0xNC4wMzUKL1N0 ZW1WIDg1Ci9YSGVpZ2h0IDQzMQovRm9udEJCb3ggWy0yOSAtOTYwIDExMTYgNzc1XQovRmxhZ3Mg NAovQ2hhclNldCAoL3BlcmlvZGNlbnRlcmVkL2FzdGVyaXNrbWF0aC9idWxsZXQpCi9Gb250Rmls ZSAyNCAwIFIKPj4gZW5kb2JqCjczIDAgb2JqClsyNzggMCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDUwMCBdCmVuZG9iago3MiAwIG9iaiA8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2Vz IFsgMCAvLm5vdGRlZiAxL3BlcmlvZGNlbnRlcmVkIDIvLm5vdGRlZiAzL2FzdGVyaXNrbWF0aCA0 Ly5ub3RkZWYgMTUvYnVsbGV0IDE2Ly5ub3RkZWZdCj4+IGVuZG9iagoyMSAwIG9iaiA8PAovTGVu Z3RoMSAxMjA2Ci9MZW5ndGgyIDUzNTQKL0xlbmd0aDMgNTMyCi9MZW5ndGggNjA5OCAgICAgIAov RmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNrtk2VclO327+kYOhREYqQRmGFQUrokBWkQ qZkBhpghhk7pULqlSxDpUEBAUUKQ7g6lO6TjzPPs/3707P3ynFfnc+Z+M991rXv9fmtd6+a4p6XD LwtDWcKVUEg0PwQEEQfKa+joyBlCBIAQkACAg0PeGW6BRqCQChZouDgQIiYGAcq6WgMFMefC4g8f iAsIAziA8ihHT2eEtQ0ayC3P81eSCFDWAe6MgFoggRoWaBu4A6YG1MIeqIOCIuBoTxBQ1t4eqP3X Gy5AbbgL3NkNDgMBIBAgDAFFAy3h1ggkAPyXJxWkFQoo8q8wzNXx30ducGcXjCkgN8YkDxBjEYZC 2nsCYXArAPgJCqMFxzj5v2HqP4srudrbP7Fw+Kv8/8zpvzIsHBD2nv+Tg3JwdEXDnYEaKBjcGfmf qQbwf9mTQ9n/l5AK2sIeAZVFWtvDgQL/CiFclBAecJgWAg21AVpZ2LvA/47DkbD/tIAZ3N8GwCpK GrKqurz/3Onfx1oWCCRa19Pxn8J/5f/NkN+MmZAzwgP4TAAkIADBJGKef/97/h9yikgoCoZAYpZC SBho4exs4QnAbAeGhIDeECACCYN7AOEeGM9gEBKFxrwCxAzFF2iFcgb8daUPhYBgG09HGzjyr/jf IWFMSPY3CQPBcr9JBAiW/01iQLDiPyQCAYIf/6YHmAH8JkwV9X9IVAAI1vpNmEyd34RRMPiHMGsD tvhNGD3oPwQRwJSB/YEYffgfKAgEW/2BGBXrP/Ahpu8/ENMz4g/EyNr9gaJAsP0fiLHh8BsxNwtG /oEYG6g/EGPD8Q/E6Dr/gRhdlz8QMyb0H4ix4foHYmy4/UZBjJDnH4hpELONFi7/auu/l1JODuXh zY+5JX5BIYG/uhADiogK+P5viVBXZ2c4Ev33F48p9m+2QmA+BDjcAw4FTI6hoI+CbVPqQ0v8FPMH 3uLzuDCmvQn+3hJSm/YItDn3iHrE+X2/Lpz5gCqEyhZRSpm8rVYGhlkJLdypl/Xp9NYBh0xQdZLR 8uSm6xDuQjdNTHG6sjvaKBwyI1YnWX46vufdnWL7Ne/Wgl+hvg4RybuzHYlXMj52dehn59+7MEmS CmNbTgY8z25ST4Lrr83H9pxvPUbloyYLu+hM0n/RXE/eaZsdspshSxOLytbAHU2TvCSGzNiUUHs/ f0JC/ond+8e6on5t1pMKZEk2LVDmaeLRxJjCQcziXuwaya/O0aSQz+VKAxxFPqOFWT1z9yvCTjhK goUiHsSEdNAh/R1KgYLoRpOZNP4UK4ppMcuR0CUbDq0KqrmeHn+3vEhZ99hnoCM3n4Jb3FBkUVZA Te6wgHnDHgdR8i475EiHkKunqQf6nLRDKcXaaBlUmQV/T0X6JhdZb0qR2cyJy98cW5SsQW8X1YZL QNzgPHXLEPjt3Do3z+71N6f76canbPKDdt91wRHkQy9JimPCTNZJ7lAOFp+fwwlOE7qVwFMlyPtO pV0lecSr5ZU/GY3F5+iJDHBpb29gs73Xjpfz5ubPuDcOL+4IpPQ6QTfu5mn08FezU3ZL6JJSZFIG WX771sUyZNSabzTOnd2RLOZRa98XpnCZPLpPUJhABUPaqyO1AW9LnDJtYgXbpSREdyD562lmlYGE jafSFH3H4jpw7qBE7jLmSJsD3XqTLdvp6Tr2EWhCuIiqCfqrw8EVg0Bn/Z2kbcHWC3+Cp08U1KqI DlvojuWHmi6rE/1LwiJo+bHqIfiVr7PZQ3+cH2mKrp8xyOgSKbOUPYoyF2VoB6+g+9jalo7D2xQ2 YSUuHinkvhv1V2HGjbmZ55TDN3VD5auyee51tD4vcO9WeU6iOXcLXMNmfM1D7IQz2gIqzkR317BP aAkF6D2STHXxN9EkX6KU3xQriMTZ6QHgnQQZA4lkurOXBxtNFXbbt1/s/1TWa5fcnrNgEKYKFmga vY/1GdRdwpp+j2v8lZlqFuDGMuYpeey3/WFdwzCO4BvxlFW6WpkJfDf9QIIpOv8du3rcRJxr/6oV wFJmvYJ1zT0nbMSH0al7vc1SDqI/vne4/pIa/BYyrEgXpLpbtPWc72W6pO/SwW6AU0PQzWnrgC7C eZUu0GdWZW2DtwvdfqRvpcgPGrlDGLr1liIh+6bPcuHrd7beYXvC+AeqpWNC56/SWwam2tGqCgCF KHKvHN41EUobfMt3YZ+n1cNifvAUzqxBkX54txtt3129+dyUJzZh4yBWoKco2pXJJ6etwCKSETni QkefnsdKbmOPbm6SNXTrcR4o542/Nan4It2CMSY1DjfsnVL/cuoltkp9orBDbIcz1bwCI6Jz1uGK jAREUd39oCRipecw4WwaKtXkI2w/cTcivlhvXhpCzRzKTUSYzKlJVtQ9Fu5lpw/GJ5lf3QKETQR8 72fgN54iIpE64zgqMtmPSpWiZylUCyr8Gkj/tXoGCsugSCsajOn/FAbpSbrssNhOzmDpqcb/UVqV 7RSj1MkTTeKTt+ily7CcG5kyipWRYYBfwstD2j20KyOCwxBdyrinNy51cwUwHbgU3VthBVRzEbzr 2Rq+Am5etRFHLqvE2Q++bwW37eDEE4cIbS58SDi4o3eo5VFVcQY7HtoxNtu+iw6mqe+lWTvF/zDt Sn3oE1J1cm/MkOQexS2DV00yxRn8kkPK4AafYKk3LNmnD8bE94TS8CATZ0wHouJFvAhsmhfKiiK2 46GeunmGMEdKJh7jC3iL1o9PFu/luh5sz8hd5ZldP6cf+KIDnUBj4fR+gvnjeiBsdCB0xYgc1iCT jWWT1/2BVJ5cNT7dgm2HmhIe2cIfRQUpbwsd3mIQt5027FZnxTYxmvOzcxQgwfJT1KgrNDV63a61 ftVu4F+I4HBzebfpfxJkhE1qyX3rBvb0MgYoE1XAHEky0bT9Q2MCef9qLWHUIVInZFImGN7/4j4j u6+1xok3B/6pipDgJsFiS75bjvUM9j6fBH26B1HO5AQRl/9YxWxP7ywhy9TnRfZdtDeAg8m89ERI T1avZohfXRgATz+iPx1FxLXSNs6Gxuvnxp7FyKCKqR+R+bHKqi1vTFV2KeYDC7v5y/jbD5xi5Xrw 7kWZ1YaZBllN+vUW673BxR+YRhWX8lss9+DlGc7c4uWr9W72Fq/KjT8iRl9jHWW/TMXyypp4TmjB t+oHPKwbBKa3xtQ5r0VGZg+TKU4wtKCnlwxltmmpUW3mqaNrCMIfdAUXilGheK2Vr/Sje+IW+FlT aZ2Yqu6Wmxuda7wP8NaSA6xcHUfo5m4nAQn483M7RInZ2QomYUXnAwrrlpWxkfmMMKZeV/GnQzQB PXpf3xvkG/IGqxHpBvz0Cd1SyKbQUqt47gquUNzUXkwNblAcpFr+6q6zykq85a5IR0/IhV+n9yXZ ekKai6eA5mMN8vZ3QVQqZISIxjpYSHlRcli8QEPTMu/DD4FgusWTHCTbWoDtmahFFws6o4tfSXkH ElYi1eF4fUXgWKjZbLpi/6XGlypetTtR5w67LW4dLRBKd0ALmaC2zC3rBcRVOmtCFpqDjj5GKjOB IUofccbzNSDf2nxwVtyPujuOcCCEMXhk/XXsyvqprENWo9KL8tY3qj9uX6ZLMj08bt8y1lh/SEu4 xJ0yw2t2mryBqtRZyJkNjmRh5q63ANqdPt89/8j5BcszWSX7TeGadNv+1Kfv7PciYMfJ5qbUhuzp UoXUrL8WrPJc8OzcZ3EOPB4VICiFT/Bq2O9fC237YIOQhjzC2nK9+sC3WN1OR0gBsWiDL2UgyYRc qt7gvKzPgr6o4/LaRIHKqT4Ry9nQTmDljonIRU2ddulK+JX+vZil61fngnOFuStUaxKj6WFCLKH+ dOlD61s+RF0isMaSQazvc8hu5jKgSTWF5zP7h5NvFBhu46BzZxmNik1OzVn0Ux/HkEZKC4CH+IRq pa/nP4Q5MnuGaw9o9iBbrnsDogkgyocIM9/1EfwDl6glA6BiU+bGLQ3Jcn91l9lrmKPcuzLWpm13 WJf4+zXkL8pnpuiRh7F4kQTAcqrzu9j7k4H1a0Dzmje1iVN7YiuP8T/GuVTXgAiWh5O89xtMeZmF bhi0c4wMzgj1L1LLclf8FiUzpO1wJrvvQOem1ei8crGY60aTBclEqXamZUPn2zeTPLzdepIp1WFj dEokaD3aUqKpGdmwNVP3NE6VVb0fg0LhWU+Gdr8OCb+DrXZbuxDrJ81wBnOEVLIrPQIxN5tmUS/t QsO/Vmxcucbc1VslT7J6RvHUcQbULTCU7aT6XaJWYsD8djd2Vgab+fpGCMnzd0dhvrqEDbRK5DDs 5huTh3uJnEb8HfU0PJyCX2vWBVVIPxngucfI6BwcEwizJ3BFWuYfc2/tZ8fqdT+G4vpYJgr9YgfD JnKNQE9pL3Bo39/CqTCnF6WaX6r1uRet/vUqOhfcua/K/OqbsolIrlVPPMnTn+Nht0t4KI7eMNf1 m7vvF5Utr5RunpdeE7TU41Z/t+Xk55Sur5EIDVGbrMQyV5M3M9rZk4WKTbZH1bAQRHj9StXgtOnM BOZ9fqjWdBzDJWt3Q2kzitPz8uqN+ddi7zakRrRxqFjQOoGczeRc13XMh61oHfr5jSvsNXGN2TaE Q6AK5dNJn1zjAy3LEwkvLB3lZdCardeI/f6DjwLGJo8XAHrwL2r54rGXc/wGA++eWjnWck3u9yvj y/UwgXKw6tLSPvHwbQlXM45e7s3kzINZXCjEOsLzHqXjG55kFcRDwVpH6zN9oik7uKg1ZgXu+6yM UzXMUuv8goYB8LfxsWfXN+KMt9WlSVzT3s6JCku5vhXu18daHzYuoO8gk2iNG2EKkR9dn7VGSRvp 7yPUhUPqM/bmT7Q6wI9fFPHvpgdE3JJnsHgVbpZZLCzngmNnIdW5ZMaDs6PUbgDi3UxfVgsUpVBO xL1l4CMecbmaNhCJYthSfeFTCycvSbrd8Or21f2TJzM63YQ0yK+e2uEJiyLoFUuC6QHzE1Aw4YsD kjMm4SkXop1XEQqivMsfL/IC5chdmvFwN/ZAPTgGnp6+pJCqNyCaHrvQNkAllT0bqxartPB9qiA4 a4cc4pDQ3Z9Rt5Vglz7e7YLYZtLVULAvQfVBKloILdSwxN5YzEub1Zc296O8aBTHdISExeuxmWR9 KEvHHdq7OeWjjzx+ADgsp7ElSd1O7+pJPLz9DIQbiBO9AluYTwl/jQL9dClnQudYKD0L/Bhi//3t +120u4pt7gMDrAY/IL8Q+/qToiOljIvD5HfHqOeWR02tBBOzup8d1ltJ8aZp03V5Jamjt0O+idZb Uf/SMuh4+BwBlMfNvjHPHWKUg5ZSpYc7jcpY+j/Bl328J17Fna7AsdY/KJqcf8S3+s60MLfu+YxE PzEyaCOe6dWtGloAVyOokhgm7RXjotd6HMbEPFGQNBAu9Uy3jmRxs+u0SwpuOZXKiR9m4sW2/Nx/ Sroz/x0JDQEhz3E0I150TlcpJzU0HexJFN/jJuyQ0csXfj7b2mMlyfdWA/yoiTfFVMRcfExmUxXO KxmsfcEwQdqiSHI7jFWfqCWL1cnEJFcY1PPgQvUzdgKR1yRBhrHvNFRG9nTiqTqjLB+0c7Vasua5 1X2LuJqpUUEqOm9Fbuo5vs0ZNvvwnwLAb+3bsxl0Upz1Vw7rES+eehu7Gf6CfFP3T2/8FjPYsi4i nTpq6tBMGe1rAjEIn9HyXPIGkF6MUseM0RQkmE7KAOqM/S0XLsocWXTouGZK5yqC7H9Aq92ZGHOC e9qE5N6WhZOEXjtuMtYErIfrGWak0FWnYw/IJRTELREuj4PY6b0j6xyxGqde2gjGLPu2RAotJLx8 kEgi366nM3bzqyo7P2A5JfbFw0yzXS1YZfke5ETb0b43uAB0qPoWd9JFSyq9+XWGUBD7GAsHwUsr dRTdPeIZw6CG0b5bjNshi3uth5SK0KSt9O46LNNGGSy6+Wjc9GteNq64qMDzWGNlt9Wby96xec0N NdBNJEXBs25uEzq2jQhyPVKC+7ENdBHuRBn5BSeUlv0NswWRr0w8d513bg/lk9e75Uqp8808qaC4 07V9Xq6T5azBzdTn7k9pJxX1qBnMp+P2uXse4cS9x3DEqeSTL/Hz1TCk2YVT3DfBmPH22HVuAXtZ /qVUzn1RQYvAKiZc6RVL0nDX2uOKrUP9Jixv3bWRBGqqTnvcR/tfyegkU6DljFqvwnnjmCO18BMH yAV1DYaNSBYI+dOd4skL5kO3JiFK5Nzs0dBrhB/zWSsfs5xRMb77OXFrvNER6ZndYgpdXDNO7PfU Tan+lrhed495fMBeisTDLKFMDfLiR+XEGvEaPji6tp+/lKlazFK6CD2YGNfX/LRIl88xlpuz74il /4Y97xIJGd3l6XMZVkZfkBqQN+cXpaFDVHV+9vnhkVtkmilimTlGLGaVOd2xFB8tqn69MTWSOOk+ sHYU7VkGeXlg3K98EGAKNCMqEKrRbFOQbgvs5Pncud46ukCJiDe1BedlT9UN3Vfpov+i91TMK7ei b99Wg8pagNN5mEh0yd78wO/Q+TEOgJDPQcNBwhnx7In+RaHM/CFo3/baifSFl4SGr7hZt8tgnfeu 8wZNb9JOU/j5se+nji9Xwsc3EhoC+tpWCJbx4CYJARANQVWdyJlnV5WHEh8c1KAZEMf0UpYz+5nr rS8LGas3ZLqIjaGPRDRiyf08UYONN9X1lvWt4scfSihGdgMbrTUWKjy6+c0EUxrTvza0cORJHRGI ng04ci0bsqrd7WxDKRGQwqJy+nbPZugjDyE4Q/To2LsnLqgh0Znqxl1ZtpnuDZFA71z/qJlAt8yT XwZ1R769DYrqWg922cTzA6ZDqqYICK08Sd98OSRqNMWpeafLe55QO4q1hwvdF3gotiHTv+eeE5W1 FghQz741GTjxa/WEPR4XbekY1K9pyCYj4aQytVhX1inIpdtAeGAUOpU3wi62cap2lerj1VvX8ULt a3naVJxXIsdndQ/Y3dR2+YYfRo2RvWwjNz3vtbtEZ/wuI3YEYHqJ8n2RT/UkTZrK8qlJVr+AICDh s/FVyrwu8eHjjfGXqpdZiuASQB0N0YDxoCwq8mIIfJHwtF+3uzxxoaby0UZVvEFNco16TXq4hFo5 paB0T2PHmYpkOItJY9w8W5Ds3SbDdnDpzRre6wxIMD/5UqfbQkFYY9wzOw0cirq4l+JmSdhRdYJB xlzgZEoSVPAVvtIHO/m59cBkm8AHudK+hbVHbzWSbKsz2YwDV7gtozovv7xSePKapqx6pkGlXy3B uXQiSLxyhaVPUdnEyzZvN6mNov2uXYlL7J2SzzD3lVD+kA4aS831u9ayyymXOgXcpEGPJAV9HSS1 uz7Upjiq6kqvSX9xuHwRtTuZv+g91nMQSA51RwzLqiS9GXxpIFPL4SGG7sAT+hWqpe6vGu4eglIB 8ASQ2XmSbIjkFyI+jX9Z8SOLifhg4EQ3a2zcYv76Ce7WyiBvBhb2TyQZKXJwfVkL5/T1B8umw5T7 Q2OR/pqBc0BlPmIsrSttC+CGx/vrixZlTcZ3q+8LhZy5Bd4mNjwov3eU01CSd+u7duP3ikT8tBao bOp3Sjz7n9XG27487HH+w2bMBM1K9zWRUxVntLQLRJlaXbNUc44vNS2fClddRHKQKdC4JdKI43z9 iM/lhMfhkOlyfDVospqp6tsrnMd3N57H/9PJPcoii+ZU5w3QHhafLMB/a0SNKZPziOlVKp3IjoIp 8Q5O98bnAG0/J8KZ0TzxDFgiolUJgVMcbnzX3IyFxrj8+wM2Mj5lba8qRsrHrIKdH7/7hYTIaKp9 Ucj28VCoXJ82wCvMxj/xG90ihXo/qUcUMwvEgIKMQKpPqnpiV5aF6d2jAH3QH261P7HGbUvsdR11 mM0UTZdYyYvkCjNzGnkhAczzfb+CfH3jZ9t13mbSHGqMJkzlHbMS7xpszWg1PFO9ZpBPTDRVGQmk Jp/Kk9JByjOY87yaUWqq67Q7Yck9Vvft7BWVoO6BQVNTQ4zGluJWcLECbx9625sTfz6Cxe1EJHcW n8osRE8rHntJKQ+4lA2SRY96FY6buzl6LfZEb99LP1f0vAPcvS62PItlhaxnuU2lj6N4GeY7HnYt Cvwf/gD/v8D/EwWg9nALZzTKwcLZDvC/AMDpLJllbmRzdHJlYW0KZW5kb2JqCjIyIDAgb2JqIDw8 Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgNzQgMCBSCi9GaXJzdENoYXIg NDUKL0xhc3RDaGFyIDEyMwovV2lkdGhzIDc1IDAgUgovQmFzZUZvbnQgL0lGTUFKVCtDTVNTQlgx MAovRm9udERlc2NyaXB0b3IgMjAgMCBSCj4+IGVuZG9iagoyMCAwIG9iaiA8PAovQXNjZW50IDY5 NAovQ2FwSGVpZ2h0IDY5NAovRGVzY2VudCAtMTk0Ci9Gb250TmFtZSAvSUZNQUpUK0NNU1NCWDEw Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMzYKL1hIZWlnaHQgNDU4Ci9Gb250QkJveCBbLTcxIC0y NTAgMTA5OSA3ODBdCi9GbGFncyA0Ci9DaGFyU2V0ICgvaHlwaGVuL0EvQi9DL0UvRy9JL0wvUC9T L1cvYS9jL2QvZS9mL2cvaC9pL2svbC9tL24vby9wL3Ivcy90L3Uvdi95L2VuZGFzaCkKL0ZvbnRG aWxlIDIxIDAgUgo+PiBlbmRvYmoKNzUgMCBvYmoKWzM2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDczMyA3MzMgNzAzIDAgNjQyIDAgNzMzIDAgMzMxIDAgMCA1ODEgMCAw IDAgNzAzIDAgMCA2MTEgMCAwIDAgMTAzOSAwIDAgMCAwIDAgMCAwIDAgMCA1MjUgMCA0ODkgNTYx IDUxMSAzMzYgNTUwIDU2MSAyNTYgMCA1MzEgMjU2IDg2NyA1NjEgNTUwIDU2MSAwIDM3MiA0MjIg NDA0IDU2MSA1MDAgMCAwIDUwMCAwIDU1MCBdCmVuZG9iago3NCAwIG9iaiA8PAovVHlwZSAvRW5j b2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA0NS9oeXBoZW4gNDYvLm5vdGRlZiA2NS9B L0IvQyA2OC8ubm90ZGVmIDY5L0UgNzAvLm5vdGRlZiA3MS9HIDcyLy5ub3RkZWYgNzMvSSA3NC8u bm90ZGVmIDc2L0wgNzcvLm5vdGRlZiA4MC9QIDgxLy5ub3RkZWYgODMvUyA4NC8ubm90ZGVmIDg3 L1cgODgvLm5vdGRlZiA5Ny9hIDk4Ly5ub3RkZWYgOTkvYy9kL2UvZi9nL2gvaSAxMDYvLm5vdGRl ZiAxMDcvay9sL20vbi9vL3AgMTEzLy5ub3RkZWYgMTE0L3Ivcy90L3UvdiAxMTkvLm5vdGRlZiAx MjEveSAxMjIvLm5vdGRlZiAxMjMvZW5kYXNoIDEyNC8ubm90ZGVmXQo+PiBlbmRvYmoKMTQgMCBv YmogPDwKL0xlbmd0aDEgMTEzNwovTGVuZ3RoMiAzODg1Ci9MZW5ndGgzIDUzMgovTGVuZ3RoIDQ2 MTcgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja7ZNlXFRtt8ZBaaRFJd3E UALDUAMCUoI0SCPlABsYGGZggkZSSlqQEkUQQVCkpUtKQjoVlQZBVEIf0nf0Oa96nvfjOZ/O7+z5 sv/XWvda1173GgiPkYmYqhPGAdTEoPFiMHHYRUBd38REDoCJS9BAIOpYEIFHYtCXEXjwIgCTl4cB qgQXQFICgMEvSklfhEnSQAB1jKcfFuniigeE1IV/JMEBVQ8Qi3REoAF9BN4V9CDWcESgABOMIxLE +4kDqigUYPzjBA4wBnEg1ht0EqeBwQAnpCMecABdkGga6A9D2mhnDAD/W3YieP475A1icURTgBDR pDBAtOiEQaP8ACfQmQZqgCH2AolO/jdM/bO4JgGFMkB4/Cj/Y0j/EUZ4IFF+/5WA8fAk4EEsoI9x ArHof6ZagH970wedkASPf0a18QgU0lEV7YICAYm/JSROE+kLOhkh8Y6ugDMChQN/6iDa6Z8miHP7 aQGqo6pxzeDqhb/v82fMCIFE4039PH9V/ZH8k2G/mTgdLNIXsJYQl5CAEROJv3+/2f6jlwbaEeOE RBMXQkYWQGCxCD8a4mYQSQYIgAFItBPoC4C+RMNQcTQGTzwCEGcSBDhjsDQ/rlNaBoC6+nm6gugf +t+SHAD1B7GY34I8AMWgwV8sIwFA8T6/4zIwIrtiwT8yJAGoM4aA/S1IEQWk9x8Z0gAUR/zEX0z0 gQO9/7AhS1RUfxPR1OXfRHSk8YvgRD+av4nYSvsXyRFjRr+JGDP5TUQPpr9InljT8RfBiNOGgn8g 8aTLH0g0h/wDiWc9fiOM2BT9BxL7YP/AH5/6B8oSp/cHwgEo4Sf+506pqWF8A8SIgxGTJN4BTEJW EoDLwoL+W6IjAYsF0fif/1fiZv6bnZHEPQZBX9CRZnoC46gQ4ZZeE/n4hkb+UDG5CKmay/Mkg8rW 0Sba8KlkUtSjXl0vkbcVlvslWSz0y+TL530OOXCxjYFXBzQ/hXolZYwfL3tfX87yr+Ow3MrS91vy 5P0Wvs7QUDO2syFDajjytu9xqtXDzpzPXesPjIQum65QvuEhabP2rmrLjpCFW2pmocyiblYISPEY M2Z4PY6Wjpr1YUxNIZsdDL/hFkVVe+H1F0wjgXk/nyr39rHNztqIivVZ7TDvvdsO+ER0umRQ4Iyy hSeB3wzBdsYlRQkeTr8Bzz3D4Xap52hC8XVcvM5T+a4sAS2Wfb92u5tP0rrZ68CvbTo67IPWpYIF X4XKsVcG3ZhJblqqR+PZ7vIRSJ9fOD52qqHIF3RQmKo4uyqdHbDbDhjqzx8IZGiMe+nAWNmdKS6z 9Xe4Of61pJtSTcmwPUVF+noDjBtNcWdtVtIlJB/KOispnkzxoJOFVyv08+J63pNwqLqBhy6dUuEa 8W2Qo9PfF5Ib6iU5ru2+/cu2/pr9pNWRSInbNueMw4n1544LvW3fk8vP2v117sj5wvUuNVysgqFg mAj59YZAqqdqe94y5wt4r9F7mHcfvHcLudvheiCe1GNYgHLoC2jpoZ02tHFv3Ry+LPUw33xk2LYn QLos8wGJEdQsXwznYuEEvZ/OdnRP5oE6DbbdFKGrQsIEJzfFHx4u+iN9v95/6FJ7TuIewiqhLSSm IUVPXkH5ixAddu5O9u5TJUb8dxZATO8Fv7z7sy35oBLRqyjQ3Z2f4YTSKaHShrRAPlLRdK7L+sMd 7U1Br87Gaw4mtNP11j2WSLrBbKigEH/m9RfnepUBX7p5Vust7vYX7ymleZd0qN/ppCY7VluGMUPd VbTpQk0Uy+aQLgtihta2tqd3fetzWXzI8vkil4sNlM6QW63zm0MgUiGvnF7QqlbjJvmzaREWZeLH dGEk7no7ealHM9W1gU9pxaRc9lgS3qdAm0YnWxa7KtK9oWkIN8LQoZg472Qy9h27ZFRXwIi35UOt QwRlgIRUsalfSYvNtHH13D31wAm1gQ7lBgEm237S++uwtG8+mfUqlvyVySbMAUhxJtaNXBofVyuO 2FaH2y6CNc5kJP1jzp8q4tgaHwfaZCTeLh6ozSm/+d2UkSe0cOXKpcIH9aTSKhprcZnkhR7XUlvh UacPuz3njGnbM+NXs1YKhurZCFpS75n4ZG04KtXW517s8e+8wSAlapoa1k4d8ZxfOux8eryFZM6J Bg0SKFm/9EpWPued/8ibC6EwMMj/RL1VJZwsOO7PKsXaxlR5d5Tes5Yqa0D/a+5ufN8wzTakZ72D L3i2znKUIFN5zkPXr+5uR6j1Lc+O1ombq4MuPSxxD+grT6NYtD4Ljt2HXwmWXo+ssCYb9Om5pIhJ cizR2EwnZeNiblLttVleTKxLgE0P3FeFp+q8axJi9CHp7oSe45R/VPDt4QjnTl74hmerSDVuNdv5 DCpsm3xGdr+fISS29FGPTfVj4/vPById1vJ8HBEE7XNTuj1FRvkNpT0TzQnNhmS7aft+m/kbXEv0 J/vWkqYfhrToeeCMtza4W05UpDGQi6plDN4RT4MFtyVRvhW6XEW3bvVGRHHgpG9ejFyD0I1AJaY1 uvPyYRNSGpGwjdpN7MlmESmpeKlO4dD6eSkm1W4BtOgwjKEMT8r67Dbk9WU/67+mzQuyPpI8bNZQ 4Addzu2UrgptP7MxamYZ34y++IHrsakR4oYu2x1Y7/LpsbbqQCPtCAR9/fOkpm8j0eoZTSI1MsHV spFC75Ry2T7uuxrN1HTgy25zkAuH6FxCJQiLufZNZRh+NDMJe//0iHEXu7DYc+je7o5Y9ym4uFZj nucfxlp1ChUgVdauQwddVXYr7g8MFbB9z7I/Vquw8H3qhQAp8yGkMXQvicfydPBcP0P3MixnSUNs 1SdCgZpzuWRAUASZ4zIx+P1LSs+H7MBOpT0OnTuue9c2+YKpZB6fqt/e+vAy3vbj8FnHQMlB7gVM NAv0ytxH9lCJoBzvQ0X7weGAGBG97zhCHYLudTqPauQww6JA9cuwJHkKLgN6C9VSg5g1vXTh8Yyg iL4PXrspKjxTqXTSyqmvQ/yUMLE2nzpHjvGdX7+yvelg+zbRoMdbc67MfdguIqbKyou1dSjiKlwP EeXLYh4NrXNnZYp4DQeqPfj1X00xUGuwOY4MxMakP7syJWNX5Ca9Tgf55DPfEkP/XaSXOsyuuziW lI/Ru4MHyNSo7nzxvcAM82ad6ZElI/ej9sYlVj1OtYBF99OQpq4zG3iAkVLDroVTN3YgCZRI/xxF K6MqGxjbeTYuSVKyBPQeoFafPIa4vYM53EnCGMpcfHTrld/HwiVy1c+PjxItWpW1RgclSgRqXoU9 KZFUOSXAu2pmNsZNvTBD1SXk+koykb5K+8u2iBiO5tV1I+DebXMKbDcy1XwlKFE/P0vXvvLLgpXy i2km3Ez/KsEMEqZRE6OvJlC0OitLdpPqA4PQ89rmC5+WuPe/8erNXjcO13YYsJXHdDLdq38ZpfLE 1Vtg84DKgiU8872xA0WiwGDCcom9Sv6Kb29hqxQX4fp6VVQ7t9Gu/FHfzII5ap+xFsuV/eSaQoBQ 5KaEsV9ryrj9iubmEuncKinr2gfPog+GPKMeupe1PeMbwDMTM1Xp/mvmoZBFPc2227rkWzRN9QrH xQVNpAH4CuYCqnTmgG1Fe2xd2Hl3VaO3GVbrlLpWhl0hHBP54SJ7pmHco1nCMlLlQbvBK+q5eiYR LwUKNEeFoWtMhX296vluZU0VtZ8UR+6brslxlBW32KaX5tNFH6icLZukemGhYsdtdOPGRUjDJbW3 JMmEefHPNAaFhjXWtT4pvjv+I3OevOyx4VasLcZHhkxDve3nz2rDJjZen+6DarKnX+ISZQfYsRo8 8HO5kJYXV6XyK/E1oZGxLVHJGzi7SosW0fncgaoY7dOOiYyk+3xp87szIy9ovHKsYsoNSfu00rUN fKSHi7ArDsNb7PDmYv7NsWA//W4YqvGvE3kt8eXLN5b6ZaG9To8Lnz1guqVLE7ToetAkVmPmzFdV YOC2Z3KFWbAzX5lwZelqRMydz2kVd9AFcZFzHs+eWaDs997GN84qTujJKseWMsZabt+inKiKNJfN pDi6f9BfcZ23vSY+5epQbvwtkh1+yHh9WxcFxe3QW/7Pdhfyg+xHx11Zvlky771JrTOYjLeTjYKX XXr1TbUbbr8ifMES72lsoj9BkdjGPtbX5gnqcwd6ldEjzuUnh5CuZx/VxZ2Pw+o0x935Roh8eqJ7 +QgayER72JOStcQq8SYkT7deFWdQXnrYJFc63tz45NLuq7gvsfCAdznCWRx3QZonm2FRmx65lvc0 xYRbGcKtr1vv3OnifqN7EMRlmETvHttpw6G+vnzx/YT254GeJ8HhasJOJ4IKhD/vvdwSjaoXmg/J TBqixn1LMonabnzSdTeHKlQ7FyVY6JPwbdO4nqldn3UvptE8Q27FKv3pxeq25QJcEfOptXzyFhBN m9lMsaHrUrQ5kCvy1C6hurxLpx/it+hMmevSTOu7nlzcJDQlOU3bV0FfUQ7mfiDhCHWGMIkd2X3V WzPmEyv9rDMbrVKyTBbjujR1cPZCmsU8jF33lGbTvLEx78KefvS94WkXOb5jTdMHqx0muS/xZvOy Uc5REYl0ke+cycXmzWW0BOOQRRmb3ujJPkx5tF5M7SnOyQwfPpLzcSv+PUoM6zGcCKV9ARmqHnbJ 6AG+YWThLRXjS2FBk7csLT0YmK+jPJmkvf0/X7hG0yxMnz5VVDl1ylC7EhPd/r6AfWg6vV6lt+JC K3kuwq1e9DmMGrK8J+Xzun1V4MT9V86t1DF6Wl14iRWd09q3RB6tjJ4RE1HmuyIHOxu+vF8WS35t vNnCaLTKpGpwnpdM6erVpa0pMnL5Y9Wg6cSDItu6sQfl8tU6p5bd1F7aDB17JTS4XT6tF9hKBidx /Z6Xw1wTkBu/G9SuEdsWX029WVzPaXqFKhc4z5Q4nTH9Yc9lbtRdcXdIaCeTD4phKrAYcmtpKI2l oOa2f5C2govstBtPckgzOBz0chqViR/4NlNAG7RUGspK5YoI2rL2jKOwuzTLZJkzKa+0Z3z/3AvB rAtvDawww0/x9F8DWwuFdAQKa5vEq0kW95I59RZD0iRE3dp69/RFE0WcZDIYyT8UkqywrVy5Er1K +p1eM7QzPmjjTSNZ+zXwxuEJF0HpSBMAn6quwxIiOOnWkYhkjCllzrblBkxpsh1mXIkLXMDkCxgP zV/Kk/SiVGhBFxWQOYW6QDVt9PI+khLoqT624Jv8lbaPU3icIx5C8r7ukVD42b8QM6nWRTjiEm56 d8aeZ0mb6LbIRl39qs4VCSm7iei11tbhwRdoF9xlizK3VkldsOB53pqndJOmZh+JHOtRfybST7YT fPYo4WO9U9PzhzJZZjvTitlj+gd3j1FtT3Y+9lVNc4+1k4gs+fW85tJ9G/zSXLHqnXG42KLS+bHp rJQKEqdMEk6xe2xazYx9PHyfyuwDZqeO5MP0c61IjxbaRvB2Fw+kmfr3WXVLgwWVN3jkTxI0DG9c 711AKz9htuyKuU6v4WFfb9lS4WnwemfY5OOlPq7b/MmJ7lhuaBXgEc5WEnpkdHLhkdYISxfNNdr2 T18KKPyrpirI5NtzKOl7rx5CGA6OE2nmijo8c6n0V0zyPlPywDFUEX1zSg/vzSkrsb68q9SmBeLp +AbTa/aVZzWKPD9cpl6/E4haV36zVZynccS5TRFpWT5YRYINlM+pmmyyqpsOO5kwa+7PFfakjINX fKS5kwnr1DiM0/Eyxa68DTo1P0ZmaSbRQJrcSs5QIt3HF2Mrhhy1PnirWXvPKuL2y3fHkqLjIc/c IlHitDUUaox5EhKxoylxajihZp5tH8W8v75ck5J1na2N1ukeivV9SiqmZ16s2XfzqRw8TtaQLKpF 9v1JRbnbtLnWrt+DJ7nk3mWnhdJLK6aYljMOAnfZK3k4ldrGxJE32Wan4KUg5WztttZZYVqGfhX6 FehXOWXR7ZOWncVp4exyzqTcPtxlVmUnPbVpydlfdRiqHzdu107X3QKyc2VmerqFCN6Y88P9S9Tr mLRsSd4PDcXw9yTNtgybXWfuV2/VZ153rQmUW2QLfDzeRq649u7VzfBZihXtc/a36DXU/EcaZaZ8 XgJDHl+0hMhlYrlbvST+hw/N/xf4P1HAEQUisHiMBwLrTvMv+PpEumVuZHN0cmVhbQplbmRvYmoK MTUgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9FbmNvZGluZyA3NiAwIFIK L0ZpcnN0Q2hhciA0NQovTGFzdENoYXIgMTE3Ci9XaWR0aHMgNzcgMCBSCi9CYXNlRm9udCAvSkFF Wk5RK0NNU1M4Ci9Gb250RGVzY3JpcHRvciAxMyAwIFIKPj4gZW5kb2JqCjEzIDAgb2JqIDw8Ci9B c2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjk0Ci9EZXNjZW50IC0xOTQKL0ZvbnROYW1lIC9KQUVaTlEr Q01TUzgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDg3Ci9YSGVpZ2h0IDQ0NAovRm9udEJCb3ggWy02 NSAtMjUwIDEwNjIgNzYxXQovRmxhZ3MgNAovQ2hhclNldCAoL2h5cGhlbi96ZXJvL29uZS90d28v dGhyZWUvZm91ci9maXZlL3NpeC9zZXZlbi9BL0QvRS9GL0kvUC9TL1QvYy9lL2cvaS9tL24vci9z L3QvdSkKL0ZvbnRGaWxlIDE0IDAgUgo+PiBlbmRvYmoKNzcgMCBvYmoKWzM1NCAwIDAgNTMxIDUz MSA1MzEgNTMxIDUzMSA1MzEgNTMxIDUzMSAwIDAgMCAwIDAgMCAwIDAgMCA3MDggMCAwIDc2NyA2 MzcgNjA4IDAgMCAyOTUgMCAwIDAgMCAwIDAgNjc5IDAgMCA1OTAgNzI2IDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCA0NzIgMCA0NzIgMCA1MzEgMCAyNTMgMCAwIDAgODQ0IDU0OSAwIDAgMCAz NjMgNDA3IDM4NCA1NDkgXQplbmRvYmoKNzYgMCBvYmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZm ZXJlbmNlcyBbIDAgLy5ub3RkZWYgNDUvaHlwaGVuIDQ2Ly5ub3RkZWYgNDgvemVyby9vbmUvdHdv L3RocmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4gNTYvLm5vdGRlZiA2NS9BIDY2Ly5ub3RkZWYgNjgv RC9FL0YgNzEvLm5vdGRlZiA3My9JIDc0Ly5ub3RkZWYgODAvUCA4MS8ubm90ZGVmIDgzL1MvVCA4 NS8ubm90ZGVmIDk5L2MgMTAwLy5ub3RkZWYgMTAxL2UgMTAyLy5ub3RkZWYgMTAzL2cgMTA0Ly5u b3RkZWYgMTA1L2kgMTA2Ly5ub3RkZWYgMTA5L20vbiAxMTEvLm5vdGRlZiAxMTQvci9zL3QvdSAx MTgvLm5vdGRlZl0KPj4gZW5kb2JqCjExIDAgb2JqIDw8Ci9MZW5ndGgxIDkxOQovTGVuZ3RoMiAy ODg0Ci9MZW5ndGgzIDUzMgovTGVuZ3RoIDM1MTMgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCnja7ZV5PJTtGsdtFWMrWwl5su9jrFmSLUvWjOyDaTyYZswwZuzGbqRskTVCWoQi ZU+kkX0XEZKlUomUbOlMved9307nz3P+Op/zPP883+v63df9+1zX/Xlu8aPWcHk9D/xZ0AiPI8rD FGCagIGFrS1MCYApKELExQ0IIJKIxuMMkURQE4BpaMAAPZIXoKQIwNQ0VVQ1VdQg4oAB3jeYgPby JgJSBtI/ROqAng9IQKOQOMACSfQGfWg1UEgsAMej0CAxWAHQw2IBmx8r/AEb0B8kBIAeChAYDPBA o4jAWdALjYNAfzgyxXniAfU/wh4k3z9TASDBn2YKkKKZlAZoFj3wOGww4AF6QqCWeNpeIM3Jf8PU 78WNSFisJdLnR/mfXfq3PNIHjQ3+pwLv40siggTAAu8BEnC/S+3BP8xZgB5oks/vWVMiEotG6eG8 sCCg+EcI7W+EDgI9rNFElDdAJJDAn2EQ5/G7B1rffjqA2joYnnS0k/3nQH8mrZFoHNE22Pevqj/U Pxn2N9PaQ0AHAc6KCoqKMJqQ9v75hfhts5M4FN4DjaOdCFU1AEkgIIMhtKNBI1UgFAagcR5gEAAG 0QxDFXB4Im0JQOtJOOCJJ0B+zFNFDYD60oaC9/gR/xlSUwGgSOJfSBsbFPk3aQBQ1F8Eo3mCgr8g TYv5BWlin78RpghAcb8gbS3+F6RtS/gFVQGo/y9I80n8BWmVA3/iv7deXx8fFCoPA+SVlFUAVSUV QE1DNfxfZCgSgQDiiD8PNW18f7InmjZrEAwCUZDnz/AordhzWTXxpeST1wZu75Gh1/eqTbWsbhl+ yBoznkaPvdFl5iczfc9hqyyXm2Nxz6Jw4I6Af2JT2Oleo49RfqnZo7uLAe6LuSH1Ag6fci2CF3xF vsa842ysGfn8XpXeami6uzTDsYSav9L+rshaytD29b4XR+lanQPut+bFqqk7GOViz1Di7kkoH7XZ n+1XmqBCmQrcn3GJaao/hnyOwlwnO7mKbyJxbV1jLkzfdWP06LVz3+X+Tt8E8KRcMWHt5egQct7x XDFNn/JfaYZUnYBXNQTvuiETrbxk+Vowc+JHtLod87Y43PW2Rx2M4b7P0ksdxXMlchpwWf26Bs7J iWb6KIPZkzM8C6lSIy8zDj9Qn9MVW+x9uZS7wZio5F6omjRaNQl3gLKXhUxL9yc1sFwaLTUizGzy +q8l5X07bD+LXJAvus+j3CGCnI8IzglfZ0xHyBwKufy1GMGTUv245rYSJltOqf2egxflyFh1Mi8d 7Nq03cUkddjN4KW7LOUui9Qi6Sc8ZLsE2UjvGfXOsAC+jFXYuU0d5e9kVqiwuKRqH/vV0D5uzN7l zJBmtqRPFt2PcijGDB/EZb0idMOqM4N64qZ2oCepNg2ZZD0HPtdB/PsnczJPhqvfRRq9mFLvhM6s rvmx1n10ueZQVn5Nm+zU9ewRgnphpq2fpUHmmLTQyZJWt9U0/Kv3xt86WA68u4L8MnymeaZz8qBD nHGAJnWlqodr6Hu1AjPjMFkpauLKHNZWGTwjUb6tqShot1WZvxKKYLpg7O1vMl2PP3EF3mc3NcxV f1zjUO+lu/DtDGS8xYE6+mNpSaxcvlQT/yf0ctP4BJ8qgb5CMwadRoOXA4WY1+JEIeb6SW8K7EZn Apb3lrbUxIsO7rgl0QIm1xQ13z7GyYLX5AEvRvBy51pVnIFBsybXfHzNQvFGueEWPGgoqWdZEcMh pVliqH8i12otWdbuxXqIRt+9doOJN97g6XAEo183JQtInG5XV4Zo2qfK5SZ8qHUK49vKtt6HuMpv n9zuyQ3vEaZyjeZ/jw3pGR4riAnEKF4oly1fpRfefMEHO5+UY2P+sG5ifEYpgvnzYo92743mHlEt e5147+HZrVL6bDMVKbqcTRanl5TAcpPbkdFYut1ptcOBJF95WaJHvhHX8t1dcqzudnE0vX3pc9O7 5aMbljedWM9AxfSxR6NfHSC5IZLPNmIZ9nz5KAFpYbiXe1ztzUhGk1bZJ64hqXIhel4UrHtnPXF8 Q3y8CNvMW1ZhyU3ncRTBprW7JQpG3beUq93ItrIKOO5p1z56zt11f1b/Npe8VQ9OcJxTVfW2HgIn 4mCdgigSE8gsFvY3xyCFEw/R9YgpPojeE/1tZ43KA9x1Wq0Qr7odanVknX/mhiSWvRLuSnen9uCp CKcowffdWIptnbvXmODdTwPx8jVOnq5z+k/PZsB10fNCHINuFhYzVpz7MnBOTd1NO210xrcxJoPO efojmkYXvG5O6muwzFiCrRky5g3xSpN+k3vPK3iXFju13KTElBB5F/TPDGRrAHC6CafK6ZQKi9V4 aKxfq289XxohTookwUgadPloz7XyAOFZx+tWMXx7MCewY8wJ3ZAY6ObY1/02Qhl63f9CW/xcfWl4 /3DJ+ny2hAtE5DRxIm9Cinz5xReFUPuZ+2UPtCvT279+e/vK+QS12auo2QzGyUvezMhN+9ZUtHBu Me+qqL1CCT4VthFUsHz4TFhYYvF10tJdpfmQdHTu2qBxpwR6iMQcdBuHRj6L4GdbzuJ17xHM5Xp9 MAbtWsg8xn4gxQA7ad554SGVklcXcwGbZ0V8Ope9W1iYKFHJUDjQqLlLuFLiHNrBgKHf+/7MedGY Yc83sVU3mA/0MPJSZNEVq2ngoHV71/U8wWAzkRblZ9Aacf7TSfhyOD4TZT9NavSTKIjjZpeuHbp5 XEAWkKEuhGQkeIQxmRnmFJ7hr31062VfMgsvMoNXldqppa7SKmGvxuIWQbW48i3jjagQ8LVxSTBz 6VVq457HT/fQS050HqHnebtmtLERD6W02jZdnlX2wi4PTuZ3jlV8eKuts6FNZHijJcGTEqrMBklX WLC11lQS/N5SHWMbOhEv62bVOMr4PfHBMXhTQYVjemopS+yd8s/jVe6kx4fo1Ocl45a2oq/KnfIN IO+b/uJQqTL9+vlGUD4jQU1xkxVG545OatTQhfej7aqP0nUVylSxdjP6eFvjBbskOMzyUM62ht+1 Kh3IbfvEWNY7C/vaJE5PjjRcyrk1oe0jJvWVrRlR8PmzYlO2C1CfU2qTnxDZlqqububONueS3tMv m8z04c5zpbH095xO/dLWl3hHJ3FmjTqCtT2n5AnTd8KyUoZsjpWWp7wSzSHbZNIZXiJAczcTv7um aZf7D1WIlkWbPzZPPYFxPrF9NtLX7DrV2OZiwzhRkjFBYDKf8WFIfc75HWwNJarGtmQ/2X429tYI 7Ih65o6TNqbLCVowdqiupqSr5jKrwsD7MnpuvxReiqlMb4w5HyjGMrCXehVY7b6fVjJxwfPcU0me hFMHkkmP+za5C8j2vG5Mhx2HBqq2rG/usVbhbxnaywyvclMePMthVJX82s7JTwVzakFPuDE4dq0I ghlCP5G5dVbNNKwojqt3SAaU2G9WKsYRjI1kF/9SLHoa0MhiT91xPspkt9lYHKC3002377iISkJH hfoG1AoHeKRk8hte3kk7moewmoCt2owIMK+ILtiONyOuC1a5KsCEY9rQG737lqpQ0QRbyIhc8K21 FPl8UW3b/dmU7TMmhPEonqm0eOxHy4Ti0RxJDi09pncB8TvuijvlW16fY+zVAKEKqlBXNXNeElN4 dJ1Zz/p0sRoxTFHiUc0+xmPHLE62Z7leNIsdRoq8WWTYnJVTLj4177KR8fFqMrFgP4JHsfW6WPyH kBJ3SkkZD/Zji8Ks9MQxbbaepKsuE4VTt+S/BByTayQqLbOstj+vmByIv7o2o23KrCeaBmtzigEE 76QFZmZ3Rm7NZtk0vw1om/PG6dffZ934FGgjYcO3U42tGkmsGqVGwP0Ne9C+XIclIveufoCtCPHz M4o1p4ma9ztiOK8saPKeG3PxPGatVRk+LD1iwK0hAkGFLyoHc7PNJ2bmkoeFi6jcCBfNV5sk09pL I/JWGFOmb28fdPriih8daO7yH93wfxN1kvO9EoYpTiznqX33GKbQpjh4yaR8Zuya0QvJdD6Tz+IF oOMVx7PnRq0lTS0N8wWChhMfCthE5JzSt0LHJDGRF8zXLf3So827pJo9b708PmEYGtZhb6CXdeu0 YRgJ/6lSdk/3HEk4OKSIDZh9Wj2KttxwFOXS/fY4hydGIWhZOWYN73kdUaSgo7jDN63Ai9YrXPmq ang/91qXGjNy3n8snWVvBu1aDTLHq/B3vqPuCliavNYpOEnurZGzgERjR9YjLGVO8ew13i9KzX85 UjBhzZ9VzzDwQt08vVZW+MjibZ3kKPLA/XSbx5DYJduvsXPvGFPCasx0VJ2BBxJ+kUFCbKTtBRnV a6j5UySB13B2epyPbioGLLdwXmQ/GFD3Psd44NDyefsImKuvJINeFzMy0YT23zdpuehmHWCXS21I 1CnT7KlXcQkND8B2fBABV9x6jz8qTB+UEpd5Il3PDT3y3GY4nnTCxLJcAFfzFs4TzkiNIuvWvmQR 7ptZ9cqcsovLYOEsbmW9dz38NIQLd6QrnyLm/Lzg2RdRalyICESGKTTIyfvtRMpRvr30PGX+B+jS TguOcdRPVC6l6CIwZZdVq6f68mdDL+ZdmvqsoOOyx3dkxC75bq1cahzfetF22Nde9HMlAV4Y9By+ EXbQor7avqCXEPPlwMI7TuGbhxoV/8MH8v8C/xMFUFgQSSDifZAEDOQftFIK9WVuZHN0cmVhbQpl bmRvYmoKMTIgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9FbmNvZGluZyA3 OCAwIFIKL0ZpcnN0Q2hhciA0NgovTGFzdENoYXIgMTE5Ci9XaWR0aHMgNzkgMCBSCi9CYXNlRm9u dCAvVFhERVlWK0NNVFQxMgovRm9udERlc2NyaXB0b3IgMTAgMCBSCj4+IGVuZG9iagoxMCAwIG9i aiA8PAovQXNjZW50IDYxMQovQ2FwSGVpZ2h0IDYxMQovRGVzY2VudCAtMjIyCi9Gb250TmFtZSAv VFhERVlWK0NNVFQxMgovSXRhbGljQW5nbGUgMAovU3RlbVYgNjUKL1hIZWlnaHQgNDMxCi9Gb250 QkJveCBbLTEgLTIzNCA1MjQgNjk1XQovRmxhZ3MgNAovQ2hhclNldCAoL3BlcmlvZC9hdC9hL2Mv ZS9rL20vbi9vL3Ivcy90L3cpCi9Gb250RmlsZSAxMSAwIFIKPj4gZW5kb2JqCjc5IDAgb2JqCls1 MTUgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUxNSAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTE1IDAgNTE1 IDAgNTE1IDAgMCAwIDAgMCA1MTUgMCA1MTUgNTE1IDUxNSAwIDAgNTE1IDUxNSA1MTUgMCAwIDUx NSBdCmVuZG9iago3OCAwIG9iaiA8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAv Lm5vdGRlZiA0Ni9wZXJpb2QgNDcvLm5vdGRlZiA2NC9hdCA2NS8ubm90ZGVmIDk3L2EgOTgvLm5v dGRlZiA5OS9jIDEwMC8ubm90ZGVmIDEwMS9lIDEwMi8ubm90ZGVmIDEwNy9rIDEwOC8ubm90ZGVm IDEwOS9tL24vbyAxMTIvLm5vdGRlZiAxMTQvci9zL3QgMTE3Ly5ub3RkZWYgMTE5L3cgMTIwLy5u b3RkZWZdCj4+IGVuZG9iago4IDAgb2JqIDw8Ci9MZW5ndGgxIDk0NAovTGVuZ3RoMiAyNDY2Ci9M ZW5ndGgzIDUzMgovTGVuZ3RoIDMxMDEgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnja7ZZpPJR7G8cRySgJEZG7KWWfGfuSMKEoGktFjjJmboxmYcxgZG2xLyNLQ4iErEWyxals haQsWTKThLKmjLXSMznndHo6L5/n1fN55n4z3+t/Xb//776u68Uttxtlq2KMJbmAZiQiRQWhitAD Dlna2iLUAIQqHCInd4gMoik4EtEETQH1AISuLgIwproBanAAoa2nrq6noQ2RAw6RPGlknJs7BZA/ pPA9SRswJoBkHAZNBCzRFHeQwNHAoPGALQmDAyk0VcAYjwdsvld4AzagN0j2AbGqEAQCwOIwFMAF dMMRIbDvjsyJriRA+48wlur515EPSPbmmALkOSYVAI5FLImIpwFY0BUCsyJx7gI5Tv4bpn4VN6Pi 8VZownf59S794xxNwOFpf2aQCJ5UCkgGLElYkEz8NfUU+Ic5SxCLoxJ+PTWnoPE4jDHRDQ8C8D9C OG8znB+IReEoGHfAFY33BtfjIBH7qwlO49YtwGyNLU4ds1H6c6Lrhyg0jkixo3n+kP2evc6Iv5nT HzLOD3CEq8LhCE4i5/nrn9Mvl5kSMSQsjshZCU0tAE0mo2kQzm5wSBM4jwBwRCzoB4B+HMcwVSKJ wikBOE0JBFxJZMj3gWrpAjDT76F10tYBYFY/SEcNgNn8IM78YOi/iVOH+UEIjjcY+BNqAjDcT8gp PfcTcm7B/40IOAAj/oQcKdJPqAHAyD8hR9n7J9QCYJSfkOPKdx3/OREkkuR3XkVLDVBR00Rw3kYH 0NbUCfy3PAyVTAaJlPVt54z1L3bFcZYABP1ADGTgJQmjf8njamVYQZBpzvNCPkVupFsV3eruw+56 wYv9Cdz4vLajXoqscvvVojRRoXG+cVnfLzu9o+oCrDvMPoR60Rm9a+M+zuNp/jU77T+lWdLGPKFL F6e23q/sYU9rch/vYrUXJDncbM6Ya5nKRsmb2L3jH9rN9cjRp+LRtUta2vZmafgT4ZfL96nvthFm eBVEaIQzfYWTrvAyOy8GeYRvqlZ69ZFURxVZzdmUlbj2G3uiy8hRwvyCz0qiCyWeeFUtMGDQ8JT3 sGyJSJV6hoVAYg/kwiqysEzS/rpMoPOtYv+UBzGnN90e79mf95V1Y22uuqgxgFCpHG1E6cDr2Ek+ dR27WdG8wkPnok/VLxXZIPk6Mgb6a9ptlOIKyBvm3q8uXhSgCuIvhBVpyKbv3fxQeWn+jW2jebz4 doZLB+VhpYaMwakdFjUbiLVJFWrP2xqhRsyTmZhrFp2CH/gnJZlzzqD1k+lL+XnBBwztu9WdyN73 pBuclTA1XF0WhNNxPgTz2Ts47RQ/Wf7Qb6LNDooFw15v6RrDFNUQi9diSEVvc4m51Ujv7Jp9mTl2 y8XUKnkLdjTOJsFtzAF6YzNi4xT+RObVgEc3ExorpJY1QkzpJw4j3yGz0mzkl2QKa2qVGue29jZW XJCdHYoGvfcKFDS5GvY01QWEWXot5nXblSyJU3lVshFD8g6lXFr6BxciKwZrYjW3r4X68EqpK548 PBhf4xVJzeDewG+KoIJJvUyp+YIbW3eObBiJ3csa9OMukX6dQie+403YHq58gSkRoN8HLqkGbC/Y XJwSysiJq5Xjs0x9N5RjPo5SZiwnpVotZZXO0F58VM0ui16u07ffKCZ9oZx7kodqby08Caj4yxnK ECrMvynJLVXrOIrtN9WWeMVf3CB13cmJXZShcbXxQlmNj+xznKY6uHlObKHXhdsn6NiLKJObAyJv CoQ+/l7rCQtxtXFTfKbdI3iY7yb5dGNUdKAn8RIB2r/t9vITNth72TfutW8l1+IZdXnz6XHSnVnh aLjwgfqZd6UlQnrkw0q7LwoPQKOG681FtsxrOOJ2cxGrqNWWTqat26L9A96fjYg86Ru0L9xdfT+O qVw6KjcveUp5YlBTo9xBxmwwUDzAKXs6+W7J2qMexiX27s/MtZwXI244aHv+hAaXUHtI6eRbQ01G lE9dkSny3N6DL1Yy9NnJ4l1hd4/Rn2+ARXIzCo/cGXi6sC9/ea+EzhAhnfBYQEXE5twlaJphlaj/ wE3Lb/4HHppKytdDnyZMnazdWhX2WUpBrpj4mlH/raJ+zktYbhEVOyKxzSPiXA5m+UmyC2kPagei 7uOGBUrQlYMnQj1sPH1qJamWPU6JsuPxd1R7LT5Ra5j2ZYOOTRns8bRvA+9tQ7Dz8ojK16yKZyO3 5jvFYvu7PnREfeShFFuHFDEe7C9V9Ctr2RbWqPzk1Mi5V3G/hRDNERlXss9SHtncLvRDDpd9cptm O6qrVf6W7sLLt3HWo1DUgxan5dSqk2lzwsHZuu0+o25C6kNtf3twOCQh8W4J0JBqZ60alKqGOD/f Q4qfjnSeDGmPCiouF1SghwAuDqPks31dB/sfLld6T2pwrzn1fK1ShLHuG5jnMCFnI8tMFMNW+16L ndOpOHlcc07rM/3kxUmPlniP8UJDXK/fNm6fUWA6YYe7L7a4yFpfeHKsV7qs+KjssQmTmNrHTR+S pd40b0E6wCtY2ZGL/ZhWR4LLh1E9tmiWLqpp9mS256GjoikV9J3wi8nah9tCpaIs9VRhH0usuPow drmfdl42E3ew6lPesiemaXLz4we3584ws6rY2bUNEm1zbX65GQ2PkQLblZEI4FXc6Fr4Q+oLiM6U ccpIl0A360V1BGGClKibHMIOvudEKH7JD3Ta58gdqwo0lWR3dmp9KW8yXssvmwzZ8sDgcIY0bWuq +K5cBy+tFGVoGefLpQ2dvgrPmMmLGGi8xcIcFejEtZ1uSw/qY/NUM+/AuM6O7hM/pOUMlxN4akvO 6bIXG5iuxdZPem55vNa9UX9EwdwZFqARCcXqRr2lhLZt9Px6L73Vn9zPepSE1WsWXbTkC8EzpVoj VrukBlM01eo3mTq9LOW61Su0h9gyqmLz4JR7sO+Ckga2Qp81dEi73DfDjWeSGhqxwA+NV4v5FlYS Tquxnz3KaLuX/YQoLKX1ySBjvrn0sHw370qT2w5JVJVuzqpypSNiyRxh/J4CQTGgCJT/eDcqqsBK XFET6Mo8Zpgwq5hXfNHC1XLXnGuxUd+mVB69GxjjwgPMI/mODAr/Yh0fquvz/sgjFv7DI0MKDa/v FISieq2eeDSk5lLqq5+hoSHNa1G2XUJJku0rmOO7oINR1InR6axbK3KMKI1bMkvqb1dX49NmdLp6 1xjVpwA5tHvY1zv48+pqAXUFPqXpzvSEeatY2Sw/T4Ns+6mdT+hlifRBO6gHX5NgVQxuNZpHRbJy uoU90gZPxIi14d4PKDw2ye006ov2ztXMtaBVvozii3io8KWcSeBjDkycNive2Ewr8SsZ+73LIEhG gVr6XIR1XeyzeCZ/RMezlRaiFVI+HRh3PLjyts8kuAN2N4cWzv1KsWlJ64wrslUEdV2tMJYL7A44 EKAoyGBVaDHz93VIDSwsrR5nZ4nWNKGk4WInZzTRwz0iUkeoZ+4J7lIei7ttZg8NjNns1su1P/6l vCVmNoWAqCkeE7psuTLKYHtEtM8Y1r6BptVlWjRadh5p0doMy9ljFFpi8FWjqDmX+zSVaFe9Bzmv PsTt/wz68oukRLJbxsTZ4xfizgZIvyTp0ja9fe8gRjBsZ+46EwhISqpLUktL9SnDMvIZydfubgve 5ZMS4xCid7XTZAE5dv0Y3eKpn+RWBaXreFkVdsPM7+0veW/sYdFzayFt9OBx9NXPQa0lrbbGyrNl R8WKCrkipoXGG9yo0ddm+PdWQ8Iydc/FAZ6qIkLNK4JMnx2vUHpIg1XpqfxNRl53P67M6V95LyRu xpeY252+qYs1v7WtB8lbdiMvZiPd3eJISdLj4LU1gaGztSaj4tdyCzvh7nlsZ/iJLLnMslR+Bczw sYVgKdW7izPm6sIfN/y+0M8jz2qBhjbu6uReDHSVILKutCt7lRvFPfhw/LOYtX7foXHPadYyVrko XjuYJvmOutt6u26n+ratWrEd5SV2BulRxm9UBPrzCdJSvLT5Qnmiwbs75028UrGesuetPPnMIUZH lboeNpO/xHy5nzdGIk5FbYhlQQYrCtATq3yqPNJ+3WYb98p11Ff23VIyG/W9LNPpcmIxYEL/eazX LPw//EH+L/A/IYDBg2gyhURAk89B/gXpLWZaZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqIDw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgODAgMCBSCi9GaXJzdENoYXIgNjkK L0xhc3RDaGFyIDExOQovV2lkdGhzIDgxIDAgUgovQmFzZUZvbnQgL1NBSldMUitDTVNTMTIKL0Zv bnREZXNjcmlwdG9yIDcgMCBSCj4+IGVuZG9iago3IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBI ZWlnaHQgNjk0Ci9EZXNjZW50IC0xOTQKL0ZvbnROYW1lIC9TQUpXTFIrQ01TUzEyCi9JdGFsaWNB bmdsZSAwCi9TdGVtViA3NgovWEhlaWdodCA0NDQKL0ZvbnRCQm94IFstNjIgLTI1MSA5NzggNzU4 XQovRmxhZ3MgNAovQ2hhclNldCAoL0UvTi9SL2EvYy9lL2kvay9sL24vby9yL3MvdC93KQovRm9u dEZpbGUgOCAwIFIKPj4gZW5kb2JqCjgxIDAgb2JqCls1ODMgMCAwIDAgMCAwIDAgMCAwIDY4NiAw IDAgMCA2MzAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ2OSAwIDQzNSAwIDQzNSAwIDAg MCAyMzAgMCA0NzUgMjMwIDAgNTAyIDQ5MCAwIDAgMzMzIDM3NSAzNTQgMCAwIDY2NSBdCmVuZG9i ago4MCAwIG9iaiA8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA2 OS9FIDcwLy5ub3RkZWYgNzgvTiA3OS8ubm90ZGVmIDgyL1IgODMvLm5vdGRlZiA5Ny9hIDk4Ly5u b3RkZWYgOTkvYyAxMDAvLm5vdGRlZiAxMDEvZSAxMDIvLm5vdGRlZiAxMDUvaSAxMDYvLm5vdGRl ZiAxMDcvay9sIDEwOS8ubm90ZGVmIDExMC9uL28gMTEyLy5ub3RkZWYgMTE0L3Ivcy90IDExNy8u bm90ZGVmIDExOS93IDEyMC8ubm90ZGVmXQo+PiBlbmRvYmoKNSAwIG9iaiA8PAovTGVuZ3RoMSA5 NzgKL0xlbmd0aDIgMjc2NwovTGVuZ3RoMyA1MzIKL0xlbmd0aCAzNDE5ICAgICAgCi9GaWx0ZXIg L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u2TeTyU+x7HKaIRBhUd0kNMCrPE2MoythLGXpJtzDwY ZjPGvoUsqTTINmQXsrTZI21kzV52OiFbi6XNie7UuafT7f5571/3dZ/nn+f9XT+/7/f3yEqZWyli CFQX0JBKYSii4CgNQM/UygqlCqDgSIisrB4dxDGIVIo+jgFqACh1dRSA8XEDDiMBlKqGkpIGWh0i C+hRaQF0ops7A5DTO/gtSBXAkEE6EY+jAKY4hjtIZtfA40iAFRVPBBkBcABDIgGW3zK8AUvQG6T7 ggQ4BIUCCEQ8A3AB3YgUCOKbIiOKKxVQ/dNM8KH95fIF6d5sUYAcW+RBgC2RQKWQAgAC6ApBYKns XiBbyX9D1K/FDX1IJCyO/K389yn9mx9HJpIC/hlBJdN8GCAdMKUSQDrl19BT4J/iTEEC0Yf8q9eI gSMR8RiKGwkEkH+aiN6GRH+QYE5k4N0BVxzJG/xuBymEX0WwB/ddAsJW3/CUlbH8Pzf63WmOI1IY 1gG0H2W/RX9n1N/Mng+d6A+cQcKRSBQ7kP3+9eXwSzMDCp5KIFLYVwKtAuDodFwAhH032IQGglAA kUIA/QHQn60YAadQGewUgD2UEMCVSod8W6gyGkC4B9DcQco3+3cTGgkgGH7UH6zCDsH8TWoAQv8H qSoBCKMfpMbONP+b2D6rH6SuDiDwPwjFPgwC/AnZsW4/Ibsl8Sdk55L/RhS7DeUnVAYQ9J+Qnev9 E6qwT/MTqgIIn+/47zvT1aX6Bymi1QDFw+wZqCupA6potZB/icP70OkghfH9f2Av/i92JbKvCQj6 g3jI8DMq/sg5j9Tq6JJQg/ye69yHOHXdapjYO/f7G/kihxI4Sdfajb0OTdy2XS9liQjMcs/u8/si 7h3XEGzRZfg23IuZNrg56+s8ywqsE7ddYZkGzNCkP0YuCt6tHlhbQnOa9U10lFw5XdB89V3LYq65 nL71K54xKY4HZ3wrH2ScU1G1NWSRbGKibsOUpCyhaV4lscox437QK4lc492RoR4xvLXyo8vUBh/h 9XzenKRNJx7HnFzIznCyhQd+Yje1YbPkcBPHjiPn1E2qZwsM+/1Eu+M+59ExQ1laD+Tr8z1iRiDm deS5sL6TDp6V0o67doxdvgca74Yi5iaPVC1GZ3XFW+5llH9myCokPV43R+2MQvPB75fAS/Xbiu8K RcmruDavJnkWVmgyELA31ixnrVZokeXFySf9ubbcckkewQd3cvUdLfTuOccTLTnA2Q5z8eQai16s tPan1Qdunc6s0NxR1PCcJPeoOGNNTKHW+O7Y1ZFCjP65kwtvzs8FH4+16N3vpAQbcn3asyumd4cM 4X6o5h9e00miXxrmNIyjVmpm9JvupNWeGUbbdzNjRy14p4SSWS2XWaret3xPfrKRwl1yvpRNMG/A 5h+4qZWekWO3u/vhfjO1+FeGGmXv4PkFDo7gWfvQYUOxwWLX7NXSGxcwz8lCa2X8tcfr4xwsOp8N OVbfK2FZn23XHK6Zj5RO4dFyvZ6SOudmK+uxTV156g6X7L0q4nDRI1+uSekuiErWFM+H4K92SXxO fgtbBaxDWtDRGTNMS9r2tt8Wpf0UODGK/ikOfZXnKx9PotfHRfiXv/Q1X93OeGGyW9LpIyKAh2NK j3m4R4Zbt2ZLkSUXESPhvv1hkEYhunCpD/0H01mCkNjyqK8/ri5d35rx/FXs9lCZkOnk+k8aYRK0 ceC0W1XAhyxfM9PxGY8yzZiOyNDyjzajUbXx7zBlZj6mr4Jcbx4TOfd28fOzkA8ueLUJTRMwNxJ6 uJ/Ed6mFW2QBnC+3ml5erjAj1zrKsJqVUr463BbLVu0/PQlpTiJOBXbqK+28lXu0Yez4GCL5POkV VpkSemXYtHYLbWE+yuPV9SZeXrnO6vjl1+LFv4HIBw7FYqF3P8eVSZZx2FlZbahrpyOXUlbtOWOf XLDNu7tNckOeJ+p++MIdDy7p+1IUebMYcdEehUmJAb2q1ZjhjOsrvVFV6FYR7XIVna7LD3r1iK+z Bme2Dvg1Y+Acb69IXpNC6T47Pak4Pypv3IB5J7NRcVNukxHYY/AMe6Y25WPYs/wJepGBWbtFydnL TRNf3SJUHYfMdYsdSqSKjxtPZ6aGqskLx71rE5C8EWvbXZI6PlRsg3nswq26ba2YVd9o3NWew6W3 17Na6rzYwkxxNdYxs3uxz0dQBGve1KD5qFXXpKLKDHfl6d6m5nXHugGSUVkvK+uglMNqbIjCG+1A I/uYiy0jRcIqRtVredPTLUMv227lOnMH6hw/oUZkYjdbVjUu7s+7bWOgJu56ayLphBPvqTPS0jvN soTxuhzVoYVWNzuYLRvq5vqc4sJFNWHbKg/mDq5yGPhl7lYMf4gY0b5+errpg3xYVFCtFY14dkma n+jwKLXENiqscGhUaatC4JfghmqD3Bwmb9yM4Ji196fgs9iUfQyB+AKzabcTvqwp2ZrFTXt3l3Dh Wqk9mP2TlZUTn8coNda2X0zTXS39kFGa870pJnqqwVJ8yzMOv6U54NRiyJ12uxhXZ7PWUOGSdVUc XpQ5/tjjijYVAzMJfMIhblUmcI7prlx7tc/kfEtq01T35rZyzXL+7HBkY28yc60/SJEBbZQai4qS 8C6R9ucd8J/N0xU27qgnGA3rL6UrKWr7U/XkHhbxv34VEdwm/AeqQLBzDwefkSHMxS74Ze1L7/bQ a8xsjQ5ovs75u+UIatqefXOxAVQdrhSeshWIcoHQ+8I4+Ta+h/EHLF4cjW0NtOIt7efEF0E+Gqap JLdUW4ytW1GmFAT22CwMk+wRmPmY+4On+RDdX6QjYDvSO2S+juM9F+5IlFNfttaXHzsO98ruv/Og /hI9eTPPGtp5lHl+2cfj48uIGtiqupzN/OU+dXoIPk+G/32j5/MbhIa32hlfCgTuh7DmP1QEqfiu 17VBwvYot13MUE7ebPu0xGTGBNzy3nqF8PmRwm9xCTJKAm9foMxWA6aAr/7cDCuuXVOHVsHUC4jD wKishzEHU5ynuAUqVv7kvnkq1iuMr6bfZfZhCh5VGiWUwrN98fbttmPXrhNlJeO3zO1GjGy9bXAy GW2nFJoV3TWa9+rB0o2eOVZt64pobfVyAub+TgQ3Tb5042m/YMZydE/OKLUrN9/Y/QI6ySyw0I0k N/j6SpJoMtQ+rdoXr1Wkf2wiAc4TKGE/9TDdInvluQBVrFKCw9mL7J2Lc1ip6lF4/PvmNlu01mJI 6/6bvEkDfkLeChyXovdkuqHwA1dnR47s5yi+VduHe+s1W7gVZmtqobleLCyJFE4u09rICrfiDe2y vb7LfzIxmb7aFJkIMXrKJzFqU1F3XKIC1qjhF1yNnkFWHWUJZSZR2/s6HUcidjpfw4acXrlUhnnI 3z1JtIvNicWnoNFOlrWxj11Iqvn6W7DCR5VrJTeDQ6y0BW04GqevOVo6L56BJ3beeJrhJDS+PXQI 06kv+7FzWG0ZBuU/NlZxGNZKFc+CXnF1F0q4VNHutyvGIYH8jHjzOdmt+bHogZ36Gt01X/NmTOTU B5v2u8yjKwXttskbRYdwDfgmuvDAY3fQyTCzSdYrZonsk95I6rrojdRe6EnBsJ60WxiP9R7uM5Ul pxf3TO5pux3hMIy8BzuCnFkyd0sn8BX83tJAme7ChqiJv9a2+LIUQcRGdhOICWKhFoZZn2gTwxsm QWlHl6OeDwRv6X6mPyKkXPNWZ+39aJmuzEkx1SxqqrZy/my6s205dBCifF5VyF5FtqhPIadGB87K DzQK8B7qMD5kz3rKzelpQevivss6dX2rQMTbYzojJjUx5ml324w0EE+1KmFKH7rrFtZbRPPWaE/P OgUs3Gb2w0WnXOOWJbYvuQpcf7FozVyj8Z/0qY6fE/ebb+pJ2CcB1zm0etF8XMqIf5p+Rvj0lrI3 Bh27LER3h5d2UB4JmOfnASaXI4SNPBnLMAHUutN4sGnhgK6ZyRa7uCcM3HteaAUAa6s+qDz6ZuJF XkbqncYgz5PcB8xKvBLtirm3Y0/Mrik4NQZgpi/r+FS5ahUKiiEZU5pW+QYq2ty/88Ru4BXa40Nz kqGBSfpKOQWnakRyoH1KQxzeB1LSXZdphytztga9Nyeo1I864+z3Oo3Hc2Td4QmNK/XqbAp0OHDs UPsfo7jMyWyZhXrrwfcjy9lY908cLVWtV7JtQRpE9aVlcaLiCbe9GZqG7fk8jTlOgMyuYznlwN66 PF3xB4916iOQw5dGPxepfiLBHxWq4JWOt382zJfE71NDC5AnxWUvHBPxtwXWg1b8Pz0Sgn6EHPDa rrtR23FqYeD9JBFdSqKum64AqelJ8qQDHxDDEi7w1/KpZVp7sCJV+ifOyVn4pYQPcYfzwTJnc0uH efoPpYbXBfSObHvBew82pMYZJSZU2R/dpHQDNtOwv35+xZxqQao69+nuFC3f5/zVyzzQjpeCVVl6 mx6B2I7SRFwmdqK54AGDSfVFprCwj3f0NBe3TbluLOnc3NAqtdl2rew1IAHYeBxxJ/Ok9gYh/8MH 8v8C/xMF8CQQR2dQyTi6J+QfMRfxb2VuZHN0cmVhbQplbmRvYmoKNiAwIG9iaiA8PAovVHlwZSAv Rm9udAovU3VidHlwZSAvVHlwZTEKL0VuY29kaW5nIDgyIDAgUgovRmlyc3RDaGFyIDQ1Ci9MYXN0 Q2hhciAxMTcKL1dpZHRocyA4MyAwIFIKL0Jhc2VGb250IC9YREZXU0srQ01TUzE3Ci9Gb250RGVz Y3JpcHRvciA0IDAgUgo+PiBlbmRvYmoKNCAwIG9iaiA8PAovQXNjZW50IDY5NAovQ2FwSGVpZ2h0 IDY5NAovRGVzY2VudCAtMTk1Ci9Gb250TmFtZSAvWERGV1NLK0NNU1MxNwovSXRhbGljQW5nbGUg MAovU3RlbVYgNzYKL1hIZWlnaHQgNDMwCi9Gb250QkJveCBbLTU4IC0yNTAgOTM5IDc1OF0KL0Zs YWdzIDQKL0NoYXJTZXQgKC9oeXBoZW4vdHdvL0EvRC9JL1AvUy9jL2UvZy9pL20vbi9yL3MvdC91 KQovRm9udEZpbGUgNSAwIFIKPj4gZW5kb2JqCjgzIDAgb2JqClszMTMgMCAwIDAgMCA0NzAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYyNSAwIDAgNjc4IDAgMCAwIDAgMjU5IDAgMCAwIDAg MCAwIDYwMCAwIDAgNTIyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQxOCAwIDQxOCAw IDQ3MCAwIDIyMyAwIDAgMCA3NDUgNDg0IDAgMCAwIDMyMCAzNjAgMzQwIDQ4NCBdCmVuZG9iago4 MiAwIG9iaiA8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA0NS9o eXBoZW4gNDYvLm5vdGRlZiA1MC90d28gNTEvLm5vdGRlZiA2NS9BIDY2Ly5ub3RkZWYgNjgvRCA2 OS8ubm90ZGVmIDczL0kgNzQvLm5vdGRlZiA4MC9QIDgxLy5ub3RkZWYgODMvUyA4NC8ubm90ZGVm IDk5L2MgMTAwLy5ub3RkZWYgMTAxL2UgMTAyLy5ub3RkZWYgMTAzL2cgMTA0Ly5ub3RkZWYgMTA1 L2kgMTA2Ly5ub3RkZWYgMTA5L20vbiAxMTEvLm5vdGRlZiAxMTQvci9zL3QvdSAxMTgvLm5vdGRl Zl0KPj4gZW5kb2JqCjE2IDAgb2JqIDw8Ci9UeXBlIC9QYWdlcwovQ291bnQgNgovUGFyZW50IDg0 IDAgUgovS2lkcyBbMiAwIFIgMTggMCBSIDMzIDAgUiA0MiAwIFIgNDUgMCBSIDU0IDAgUl0KPj4g ZW5kb2JqCjU5IDAgb2JqIDw8Ci9UeXBlIC9QYWdlcwovQ291bnQgMQovUGFyZW50IDg0IDAgUgov S2lkcyBbNTcgMCBSXQo+PiBlbmRvYmoKODQgMCBvYmogPDwKL1R5cGUgL1BhZ2VzCi9Db3VudCA3 Ci9LaWRzIFsxNiAwIFIgNTkgMCBSXQo+PiBlbmRvYmoKODUgMCBvYmogPDwKL1R5cGUgL0NhdGFs b2cKL1BhZ2VzIDg0IDAgUgo+PiBlbmRvYmoKODYgMCBvYmogPDwKL1Byb2R1Y2VyIChwZGZlVGVY LTEuMjFhKQovQ3JlYXRvciAoVGVYKQovQ3JlYXRpb25EYXRlIChEOjIwMDcxMjAyMDAyNDIwLTA4 JzAwJykKL1BURVguRnVsbGJhbm5lciAoVGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9uIDMuMTQxNTky LTEuMjFhLTIuMiAoV2ViMkMgNy41LjQpIGtwYXRoc2VhIHZlcnNpb24gMy41LjQpCj4+IGVuZG9i agp4cmVmCjAgODcKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwNTc4IDAwMDAwIG4gCjAwMDAw MDA0NjMgMDAwMDAgbiAKMDAwMDAwMDAwOSAwMDAwMCBuIAowMDAwMDYyMTU0IDAwMDAwIG4gCjAw MDAwNTg0NjEgMDAwMDAgbiAKMDAwMDA2MTk5OCAwMDAwMCBuIAowMDAwMDU3ODI3IDAwMDAwIG4g CjAwMDAwNTQ0NTIgMDAwMDAgbiAKMDAwMDA1NzY3MSAwMDAwMCBuIAowMDAwMDUzODAxIDAwMDAw IG4gCjAwMDAwNTAwMTEgMDAwMDAgbiAKMDAwMDA1MzY0MyAwMDAwMCBuIAowMDAwMDQ5MTc3IDAw MDAwIG4gCjAwMDAwNDQyODMgMDAwMDAgbiAKMDAwMDA0OTAyMCAwMDAwMCBuIAowMDAwMDYyODg0 IDAwMDAwIG4gCjAwMDAwMDE0NDEgMDAwMDAgbiAKMDAwMDAwMTMyMyAwMDAwMCBuIAowMDAwMDAw NjgxIDAwMDAwIG4gCjAwMDAwNDM0MTIgMDAwMDAgbiAKMDAwMDAzNzAzNCAwMDAwMCBuIAowMDAw MDQzMjUyIDAwMDAwIG4gCjAwMDAwMzY2MDYgMDAwMDAgbiAKMDAwMDAzNDkwNSAwMDAwMCBuIAow MDAwMDM2NDUwIDAwMDAwIG4gCjAwMDAwMzM2MDEgMDAwMDAgbiAKMDAwMDAyNTIwMyAwMDAwMCBu IAowMDAwMDMzNDQzIDAwMDAwIG4gCjAwMDAwMjQ0MjkgMDAwMDAgbiAKMDAwMDAxNzkwMyAwMDAw MCBuIAowMDAwMDI0MjcxIDAwMDAwIG4gCjAwMDAwMDI2MDYgMDAwMDAgbiAKMDAwMDAwMjQ4OCAw MDAwMCBuIAowMDAwMDAxNTU5IDAwMDAwIG4gCjAwMDAwMTc0NDUgMDAwMDAgbiAKMDAwMDAxNDIx NCAwMDAwMCBuIAowMDAwMDE3Mjg4IDAwMDAwIG4gCjAwMDAwMTM3NzAgMDAwMDAgbiAKMDAwMDAx MTM0OSAwMDAwMCBuIAowMDAwMDEzNjE0IDAwMDAwIG4gCjAwMDAwMDM4ODAgMDAwMDAgbiAKMDAw MDAwMzc2MiAwMDAwMCBuIAowMDAwMDAyNzQ3IDAwMDAwIG4gCjAwMDAwMDUyOTggMDAwMDAgbiAK MDAwMDAwNTE4MCAwMDAwMCBuIAowMDAwMDA0MDA5IDAwMDAwIG4gCjAwMDAwMTEwNDggMDAwMDAg biAKMDAwMDAwOTY2MyAwMDAwMCBuIAowMDAwMDEwODk0IDAwMDAwIG4gCjAwMDAwMDkzNjEgMDAw MDAgbiAKMDAwMDAwNzQ5NiAwMDAwMCBuIAowMDAwMDA5MjA2IDAwMDAwIG4gCjAwMDAwMDY0MTcg MDAwMDAgbiAKMDAwMDAwNjI5OSAwMDAwMCBuIAowMDAwMDA1NDYyIDAwMDAwIG4gCjAwMDAwMDcz OTAgMDAwMDAgbiAKMDAwMDAwNzI3MiAwMDAwMCBuIAowMDAwMDA2NTIzIDAwMDAwIG4gCjAwMDAw NjI5OTIgMDAwMDAgbiAKMDAwMDAwOTU4MCAwMDAwMCBuIAowMDAwMDA5NTU3IDAwMDAwIG4gCjAw MDAwMTEyNzYgMDAwMDAgbiAKMDAwMDAxMTI1MyAwMDAwMCBuIAowMDAwMDE0MDcyIDAwMDAwIG4g CjAwMDAwMTM5OTkgMDAwMDAgbiAKMDAwMDAxNzczMCAwMDAwMCBuIAowMDAwMDE3NjU1IDAwMDAw IG4gCjAwMDAwMjQ4NjUgMDAwMDAgbiAKMDAwMDAyNDY4MiAwMDAwMCBuIAowMDAwMDM0Mzg2IDAw MDAwIG4gCjAwMDAwMzQwMjMgMDAwMDAgbiAKMDAwMDAzNjg5NiAwMDAwMCBuIAowMDAwMDM2ODQx IDAwMDAwIG4gCjAwMDAwNDM5MjUgMDAwMDAgbiAKMDAwMDA0MzY4MyAwMDAwMCBuIAowMDAwMDQ5 NjcxIDAwMDAwIG4gCjAwMDAwNDk0NTIgMDAwMDAgbiAKMDAwMDA1NDIxOCAwMDAwMCBuIAowMDAw MDU0MDI1IDAwMDAwIG4gCjAwMDAwNTgxOTkgMDAwMDAgbiAKMDAwMDA1ODA0OCAwMDAwMCBuIAow MDAwMDYyNTg1IDAwMDAwIG4gCjAwMDAwNjIzODYgMDAwMDAgbiAKMDAwMDA2MzA2NiAwMDAwMCBu IAowMDAwMDYzMTMyIDAwMDAwIG4gCjAwMDAwNjMxODMgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6 ZSA4NwovUm9vdCA4NSAwIFIKL0luZm8gODYgMCBSCi9JRCBbPDY1NEU3QzMwMDY2QjRBN0VGOUUz NUQ3RDRCQkZFQkQyPiA8NjU0RTdDMzAwNjZCNEE3RUY5RTM1RDdENEJCRkVCRDI+XQo+PgpzdGFy dHhyZWYKNjMzODYKJSVFT0YK --Multipart_Sun_Dec__2_21:07:44_2007-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Sun_Dec__2_21:07:44_2007-1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Multipart_Sun_Dec__2_21:07:44_2007-1-- From p2psip-bounces@ietf.org Mon Dec 03 00:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4Il-0002Nx-Lc; Mon, 03 Dec 2007 00:57:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4Ik-0002NN-Kj for p2psip@ietf.org; Mon, 03 Dec 2007 00:57:06 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz4Ij-0005Qe-P0 for p2psip@ietf.org; Mon, 03 Dec 2007 00:57:06 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB35uWP7029175; Mon, 3 Dec 2007 07:57:03 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 07:56:41 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 07:56:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Mon, 3 Dec 2007 07:59:36 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F0581B4E5@esebe102.NOE.Nokia.com> In-Reply-To: <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] More thoughts on clients, peers, and services, and service routing Thread-Index: Acgzwcet1wIoqJLURzubI2Bvu3F9gwBqoPng References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com><47509618.7060001@cisco.com> <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> From: To: X-OriginalArrivalTime: 03 Dec 2007 05:56:41.0946 (UTC) FILETIME=[4709CBA0:01C83571] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Dean, In my opinion there is a room for both solutions, however I would opt for the second one. The good thing about the first solution is that it allows conventional SIP UAs to use resources of the overlay. The problem with this approach is that it is limited to the current SIP model (with its limitations), faces security challenges, and does not allow for non-SIP applications. Both solutions can be implemented with P2PP. Marcin >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 30 November, 2007 18:27 >To: Paul Kyzivat >Cc: P2PSIP Mailing List >Subject: Re: [P2PSIP] More thoughts on clients, peers, and=20 >services,and service routing > > >On Nov 30, 2007, at 5:00 PM, Paul Kyzivat wrote: > >> Dean, >> >> Very interesting stuff you wrote below. > >Thanks. I think "interesting" is a good adjective. Far more=20 >polite than "deranged", which probably came to mind for at=20 >least a few readers. > >> >> A related question: >> >> in a regular sip network, UAs often "hide behind" a proxy - the =20 >> proxy acts as a screening device. It also acts as a policy agent =20 >> for selecting which of possibly several UAs for the AOR gets a =20 >> call. (It may also do callerprefs but typically callee policy takes =20 >> precedence.) >> >> Is any of this behavior in scope for P2PSIP? Is it part of the =20 >> finding function, the routing function, or some new function? >> > >I've been pondering that question for some time. > >Either we lose much of the functionality built into SIP proxies =20 >(which includes what you list above along with, to my mind, the far =20 >more important function of hiding the UA's IP address unless proxy =20 >policy lets the request through), or we have to find a new way to =20 >provide those functions. > >I think this could take two forms, one novel, one conventional. > >In the conventional approach, the "peer" that would be found using a =20 >"get" on a AOR resource is a SIP proxy, and once it gets a SIP =20 >request, it applies the usual policy decisions before passing the =20 >request on to the end UA. This "passing on" could be done using =20 >conventional SIP, or it could be done using the overlay. What makes =20 >it work is the same sort of indirection that maps AOR to Contact to =20 >User. We'd just introduce an intermediary resource ID. In effect, =20 >Alice might insert her two phones "alice-1@example.com" and =20 >"alice-2@example.com" into the overlay, and her proxy peer might =20 >insert "alice@example.com" and be configured with a policy table that =20 >applies "contact routing" towards the phones. We can even think of =20 >using a SIP REGISTER request, routed over the overlay, to inform the =20 >proxy peer about the downstream bindings. Perhaps there is even a way =20 >to apply CPL in this sort of model. > >A more novel approach would be to put the traditional "proxy policy" =20 >functions into the overlay. One approach would be to have a "policy =20 >language", and for each AOR, put a policy resource into the overlay. =20 >Before sending a message, a peer would first do a "get" on the policy =20 >resource, then interpret the policy resource before dispatching the =20 >request. For example, the policy resource for "alice@example.com" =20 >might indicate that she's busy next week and all calls should be =20 >retargeted to "alice@voicemail.example.com". Alice's various devices =20 >(assuming she has more than one) might achieve the effect of SIP =20 >contact-registration by amending Alice's policy resource to add =20 >themselves to the policy. > > >I think the current models rather naively assume "one AOR, one =20 >device" and that any policy enforcement can be done in the =20 >terminating device. There's probably an underlying assumption that =20 >any more complex policy gets handled by something analogous to a =20 >B2BUA, but I don't think it really has to work that way. Indeed, I =20 >expect to see all sorts of policy-driven indirection models working =20 >their way into the overlay once we get the basic functions sorted =20 >out. But that does raise the question of the system being more =20 >effective if we build these functions in up front. > >Here's a nifty use case: Let's say Alice only wants Bob and Charlie =20 >to be able to deduce her location from the overlay. The resource =20 >"alice@example.com" might, instead of returning a Contact, instead =20 >return only a policy object. That policy object might contain =20 >sections encrypted with Bob and Charlie's public keys. Each section, =20 >when decrypted, would provide a retargeting to an anonymous resource =20 >ID that Alice minted for temporary use. Bob "calls" alice, "getting" =20 >the resource record "alice@example.com", finds it to be a policy =20 >object that has a section keyed for him, decrypts it, finds that it =20 >contains instructions to retarget to another resource, does a =20 >"connect" on that resource, and is connected to Alice's phone. > >These are the kinds of things that can happen when we start thinking =20 >of the overlay as a distributed database, not just as a distributed =20 >proxy-registrar. > >-- >Dean > > > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 09:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCZK-000146-EM; Mon, 03 Dec 2007 09:46:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzCZJ-0000xu-LQ for p2psip@ietf.org; Mon, 03 Dec 2007 09:46:45 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzCZJ-0001t9-2P for p2psip@ietf.org; Mon, 03 Dec 2007 09:46:45 -0500 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Mon, 03 Dec 2007 06:46:22 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB3Ei5OP008734; Mon, 3 Dec 2007 06:44:05 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB3EkHRC008095; Mon, 3 Dec 2007 06:46:17 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 06:46:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] 500+ Node Overlay using P2PP Date: Mon, 3 Dec 2007 06:44:07 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE37F@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] 500+ Node Overlay using P2PP Thread-Index: Acg1aO6Hgtz0cvlARbu3jFBhNB0CUwAUbKCA References: From: "Henry Sinnreich" To: "Salman Abdul Baset" , X-OriginalArrivalTime: 03 Dec 2007 14:46:17.0422 (UTC) FILETIME=[42B2A6E0:01C835BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Salman, Thanks for sharing! This deployment gives a great amount of credibility to the work of the P2PSIP WG and marks a historic point for P2PSIP. Henry -----Original Message----- From: Salman Abdul Baset [mailto:salman@cs.columbia.edu]=20 Sent: Sunday, December 02, 2007 10:56 PM To: p2psip@ietf.org Subject: [P2PSIP] 500+ Node Overlay using P2PP We have implemented Kademlia and Bamboo over P2PP and are currently=20 running a 500+ node overlay on 160+ planet lab machines. The=20 implementation uses the reliability model of P2PP and is compliant to=20 P2PP-01 draft. We have overlayed the routing and resource tables of nodes=20 on google map. The routing and resource tables of 160 live nodes can be=20 viewed at: http://www1.cs.columbia.edu/~gg2265/kad3/ The display script is a bit slow and we are working to improve it. A rendering from an earlier run of 50 nodes can be found at: http://www1.cs.columbia.edu/~salman/p2pp/planet/ I plan to release a 'client' executable very soon which folks can use to insert key value pairs in the overlay and view the results immediately on=20 nodes. Regards, Salman _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 12:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFIO-0003km-9H; Mon, 03 Dec 2007 12:41:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFIM-0003kQ-60 for p2psip@ietf.org; Mon, 03 Dec 2007 12:41:26 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFIL-0005FI-Gv for p2psip@ietf.org; Mon, 03 Dec 2007 12:41:25 -0500 Received: from wooky.tm.uka.de (dhcp-11fb.ietf70.org [130.129.17.251]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1IzFIG1OGK-0001cz; Mon, 03 Dec 2007 18:41:24 +0100 Message-ID: <47543FBE.9080608@tm.uka.de> Date: Mon, 03 Dec 2007 18:41:18 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Salman Abdul Baset Subject: Re: [P2PSIP] 500+ Node Overlay using P2PP References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX18rdaJJsryflvHwUJaac3BmylIA2l62MKk20st 7Ui9rBOT6wx5i0nOURJ3EK2NiBqibkm2UBwKHJ3ivACmevzOzx y+C4XPbumIALA7U2KCpzaoxx3kNcFA2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Nice work! Do you also intend to release the source code of your implementation? Is the currently deployed overlay on PlanetLab based on Kademlia or Bamboo? Regards, Ingmar Salman Abdul Baset wrote: > We have implemented Kademlia and Bamboo over P2PP and are currently > running a 500+ node overlay on 160+ planet lab machines. The > implementation uses the reliability model of P2PP and is compliant to > P2PP-01 draft. We have overlayed the routing and resource tables of > nodes on google map. The routing and resource tables of 160 live nodes > can be viewed at: > > http://www1.cs.columbia.edu/~gg2265/kad3/ > > The display script is a bit slow and we are working to improve it. > > A rendering from an earlier run of 50 nodes can be found at: > http://www1.cs.columbia.edu/~salman/p2pp/planet/ > > I plan to release a 'client' executable very soon which folks can use to > insert key value pairs in the overlay and view the results immediately > on nodes. > > Regards, > Salman > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 13:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFcA-0003SQ-LV; Mon, 03 Dec 2007 13:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFcA-0003SL-7r for p2psip@ietf.org; Mon, 03 Dec 2007 13:01:54 -0500 Received: from chip2og55.obsmtp.com ([64.18.13.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFc9-0005ap-Me for p2psip@ietf.org; Mon, 03 Dec 2007 13:01:54 -0500 Received: from source ([192.150.11.134]) by chip2ob55.postini.com ([64.18.5.12]) with SMTP; Mon, 03 Dec 2007 10:01:46 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB3HxXOP005483; Mon, 3 Dec 2007 09:59:34 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lB3I0KFb021857; Mon, 3 Dec 2007 10:01:23 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 03:01:22 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Initial slides for Wednesday Date: Mon, 3 Dec 2007 10:01:13 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> In-Reply-To: <20071203050744.C50D033C47@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Initial slides for Wednesday Thread-Index: Acg1azwXgBfRciseQqOB3rJwioyk/wAaag6w References: <20071203050744.C50D033C47@delta.rtfm.com> From: "Henry Sinnreich" To: "Eric Rescorla" , X-OriginalArrivalTime: 03 Dec 2007 18:01:22.0201 (UTC) FILETIME=[834A3090:01C835D6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Certificates are a critical tool, but are they the only tool as implied in slides?=20 What a about other schemas that may be more effective as the case may be: At the p2p overlay, for routing, checking the consistency of the routing table entries can tell us if there are misbehaving nodes: http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf=20 Between the app and p2p layers, secure interfaces are also defined in the above. At the application layer, I don't need certs for the entries in the buddy list. Who is not my buddy (organizations) can be found and contacted on the web. I suggest adding some words to the effect when certificates are a good option and what alternatives there are, for what scenarios. Note: As H. Schulzrinne has mentioned, certifying a party that decides to act with malice does not help with security. Observing malicious behavior will do the trick far better. Henry -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Sunday, December 02, 2007 11:08 PM To: p2psip@ietf.org Subject: [P2PSIP] Initial slides for Wednesday Here are my prototype slides for Tuesday's discussion. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 13:10:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFkl-0002Rq-Cp; Mon, 03 Dec 2007 13:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFkk-0002RJ-96 for p2psip@ietf.org; Mon, 03 Dec 2007 13:10:46 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFkj-0006MT-QO for p2psip@ietf.org; Mon, 03 Dec 2007 13:10:46 -0500 Received: by nz-out-0506.google.com with SMTP id n1so2134851nzf for ; Mon, 03 Dec 2007 10:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Jr4jASfNMggDSzSr2nfTkcBlW7XbyJA3KdNxUcuf0p0=; b=Auusik0SUf01p2zWk0/jIhXr9MGkQ95qfDHiFJA7PH0demAv3YW7WZmMdZtes0EzFZ++D8q6PZun0CKZ8BC8+5GDMTrrT/2otO67BBhJN6S+INl6ivjL0k3YjVPmpT2CQW9g3KTKgAnASvogEs/6F0IM1pXGuQc9qw7O3E+inhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=WD5thF/AYNAmCzIHNVd7mMwQQbE6WGoChuLXpoR2jBe3ql9X8eYHYRe0V1mUzAtWhdCJcG4JNvG9NyMzpMu4Du7LFqwl/Gn2FKGeicrlMJOzakRrnkekScEf01hnuQ3obh06SwgNO6SIQcSglRFUDapfevxGEbxl7QM4ZlLRu48= Received: by 10.142.226.2 with SMTP id y2mr1583138wfg.1196705443915; Mon, 03 Dec 2007 10:10:43 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 3 Dec 2007 10:10:43 -0800 (PST) Message-ID: <20d2bdfb0712031010p2eb1ee60t210cb9f2e4d0f4e8@mail.gmail.com> Date: Mon, 3 Dec 2007 10:10:43 -0800 From: "Bruce Lowekamp" To: "Henry Sinnreich" Subject: Re: [P2PSIP] Initial slides for Wednesday In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071203050744.C50D033C47@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> X-Google-Sender-Auth: aeb0fad4fa3421f1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry, I think you're right that there are other aspects to the security problem. Observing routing behavior is a very useful step since it helps when an attacker gains control of a peerid. Relying on user-level authentication can also be useful in certain scenarios. As that OSDI paper states, these techniques are complementary to, not alternatives to, established techniques for authentication such as certificates. But we do need to discuss both. Bruce On 12/3/07, Henry Sinnreich wrote: > Certificates are a critical tool, but are they the only tool as implied > in slides? > > What a about other schemas that may be more effective as the case may > be: > > At the p2p overlay, for routing, checking the consistency of the routing > table entries can tell us if there are misbehaving nodes: > > http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf > > Between the app and p2p layers, secure interfaces are also defined in > the above. > > At the application layer, I don't need certs for the entries in the > buddy list. Who is not my buddy (organizations) can be found and > contacted on the web. > > I suggest adding some words to the effect when certificates are a good > option and what alternatives there are, for what scenarios. > > Note: As H. Schulzrinne has mentioned, certifying a party that decides > to act with malice does not help with security. Observing malicious > behavior will do the trick far better. > > Henry > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Sunday, December 02, 2007 11:08 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Initial slides for Wednesday > > Here are my prototype slides for Tuesday's discussion. > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 13:25:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFyp-0005xf-I4; Mon, 03 Dec 2007 13:25:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFyn-0005rE-Jl for p2psip@ietf.org; Mon, 03 Dec 2007 13:25:17 -0500 Received: from chip2og55.obsmtp.com ([64.18.13.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFyn-0007a4-4G for p2psip@ietf.org; Mon, 03 Dec 2007 13:25:17 -0500 Received: from source ([192.150.11.134]) by chip2ob55.postini.com ([64.18.5.12]) with SMTP; Mon, 03 Dec 2007 10:24:54 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB3IMZOP010161; Mon, 3 Dec 2007 10:22:37 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lB3IOPFb024999; Mon, 3 Dec 2007 10:24:46 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 03:24:26 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Initial slides for Wednesday Date: Mon, 3 Dec 2007 10:24:20 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE386@namail5.corp.adobe.com> In-Reply-To: <20d2bdfb0712031010p2eb1ee60t210cb9f2e4d0f4e8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Initial slides for Wednesday Thread-Index: Acg119tYEPuN4rn3RKqAllv78xOLTAAAR+Jg References: <20071203050744.C50D033C47@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> <20d2bdfb0712031010p2eb1ee60t210cb9f2e4d0f4e8@mail.gmail.com> From: "Henry Sinnreich" To: "Bruce Lowekamp" X-OriginalArrivalTime: 03 Dec 2007 18:24:26.0263 (UTC) FILETIME=[BC414A70:01C835D9] X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Philip Zimmermann , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Thanks Bruce for the agreement! I should have added that a possible lightweight solution at the application layer is to just store ZRTP "somethings" in my address book. There would be no ZRTP entries for "uninteresting contacts" :-) Reminder: What is the status of the ZRTP I-D?=20 We may need it for P2PSIP sooner than later. Henry -----Original Message----- From: lowekamp@gmail.com [mailto:lowekamp@gmail.com] On Behalf Of Bruce Lowekamp Sent: Monday, December 03, 2007 12:11 PM To: Henry Sinnreich Cc: Eric Rescorla; p2psip@ietf.org Subject: Re: [P2PSIP] Initial slides for Wednesday Henry, I think you're right that there are other aspects to the security problem. Observing routing behavior is a very useful step since it helps when an attacker gains control of a peerid. Relying on user-level authentication can also be useful in certain scenarios. As that OSDI paper states, these techniques are complementary to, not alternatives to, established techniques for authentication such as certificates. But we do need to discuss both. Bruce On 12/3/07, Henry Sinnreich wrote: > Certificates are a critical tool, but are they the only tool as implied > in slides? > > What a about other schemas that may be more effective as the case may > be: > > At the p2p overlay, for routing, checking the consistency of the routing > table entries can tell us if there are misbehaving nodes: > > http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf > > Between the app and p2p layers, secure interfaces are also defined in > the above. > > At the application layer, I don't need certs for the entries in the > buddy list. Who is not my buddy (organizations) can be found and > contacted on the web. > > I suggest adding some words to the effect when certificates are a good > option and what alternatives there are, for what scenarios. > > Note: As H. Schulzrinne has mentioned, certifying a party that decides > to act with malice does not help with security. Observing malicious > behavior will do the trick far better. > > Henry > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Sunday, December 02, 2007 11:08 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Initial slides for Wednesday > > Here are my prototype slides for Tuesday's discussion. > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 13:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGGf-00006T-5U; Mon, 03 Dec 2007 13:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGGe-00006E-Oq for p2psip@ietf.org; Mon, 03 Dec 2007 13:43:44 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGGe-000156-10 for p2psip@ietf.org; Mon, 03 Dec 2007 13:43:44 -0500 Received: by nz-out-0506.google.com with SMTP id n1so2149481nzf for ; Mon, 03 Dec 2007 10:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=hb1Xjh/1Gh6Jn6l7fr0wI3xPv3/hx/ev8eSsU4+VF3Y=; b=rO3W6h2C1T9pVE6Q+Z0rRFdh4ZyVSAMWjkpSU94FNdFPeiiOjI7dcoST02t5uusq0FX+Lh4igswQTpsOW+yfJL0MwbZehpz5hbolpDMVHT7WAp41QLMJnaaYi7yHXx4829x4JPQhBXDsU5yQoTMBK3bCApzNI1jRmrv9ZqkANaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=o6GQbvTA4aORBRj5UeDt3V1xMPwsB2Zugv3+n6ObiyhahzS+712OmpBeKMnFR62VV8cKLsTen/vKPb8hyePsoMHhdUI9fqK96wa/U/kbqQXf6ZUFsKJfj2AaUEze/OE4MiLhW3ccAyWE9jaIr6vPOjxQP9L1mx7/pwElsNTbtS8= Received: by 10.142.99.21 with SMTP id w21mr1413445wfb.1196707422840; Mon, 03 Dec 2007 10:43:42 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 3 Dec 2007 10:43:42 -0800 (PST) Message-ID: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> Date: Mon, 3 Dec 2007 10:43:42 -0800 From: "Bruce Lowekamp" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10823_16284663.1196707422812" X-Google-Sender-Auth: 432e9313f7888b49 X-Spam-Score: 1.2 (+) X-Scan-Signature: dce614827510b4050294eeec86a3642d Subject: [P2PSIP] replication for p2psip X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org ------=_Part_10823_16284663.1196707422812 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSdtIGF0dGFjaGluZyBhIGZpcnN0IGRyYWZ0IG9mIHNsaWRlcyBmb3IgdGhlIHJlcGxpY2F0aW9u IGRpc2N1c3Npb24Kb24gV2VkbmVzZGF5LiAgKEknbSBhbHNvIGluY2x1ZGluZyB0aGUgcmF3IHRl eHQgYmVsb3csIHdoaWNoIGlzIGEKbGl0dGxlIGJpdCBoYXJkIHRvIHJlYWQuKSAgSSBoYXZlIHRy aWVkIHRvIHN1bW1hcml6ZSB0aGUgaW1wb3J0YW50CmNvbmNlcHRzIGFuZCBpc3N1ZXMsIGFuZCBh dCB0aGUgZW5kIEkgcHJvcG9zZSBhIGhpZ2gtbGV2ZWwgdmlldyBvZiBhCnNvbHV0aW9uLCBhcyBJ IHBlcmNlaXZlIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBlYXJsaWVyIGVtYWlsIHRocmVhZHMuCgpJ IHdvdWxkIGFwcHJlY2lhdGUgc3BlY2lmaWMgY29tbWVudHMgb24gdGhlIHNsaWRlcywgbWlzc2lu ZyBpbXBvcnRhbnQKaXNzdWVzLCBvciBqdXN0IGdlbmVyYWwgY29udmVyc2F0aW9uIG9uIHRoZXNl IGlzc3Vlcy4KCkJydWNlCgoKClJlcGxpY2F0aW9uIGZvciBQMlBTSVAKQnJ1Y2UgTG93ZWthbXAK MTIvNS8yMDA3CjIKUmVwbGljYXRpb24gdnMgRXJhc3VyZSBDb2RlcwpUaGlzIHRhbGsgZGlzY3Vz c2VzICJyZXBsaWNhdGlvbi4iICBGb3IKUDJQU0lQLCB3aGVyZSB0aGUgcHJpbWFyeSByZXNvdXJj ZSBpcwphIEFvUi0+VVJJIG9yIHNpbWlsYXIgbWFwcGluZywgdGhpcyBpcwp0aGUgcmlnaHQgYXBw cm9hY2guICBGb3Igc3RvcmFnZSBvZgpsYXJnZXIgb2JqZWN0cywgbWVjaGFuaXNtcyBzdWNoIGFz CmVyYXN1cmUgY29kZXMgYXJlIG1vcmUgYXBwcm9wcmlhdGUuCk1vc3Qgb2YgdGhlIHNhbWUgaXNz dWVzIG9mIHBsYWNlbWVudAphbmQgcmVzcG9uc2liaWxpdHkgYXJlIHN0aWxsIGFwcGxpY2FibGUK d2l0aCBvbmx5IHNsaWdodCBtb2RpZmljYXRpb25zLgozClRoZSBRdWVzdGlvbnMKV2hhdCBzaG91 bGQgcmVwbGljYXRpb24gYWNoaWV2ZT8KV2hhdCBwZWVyIGlzIHJlc3BvbnNpYmxlIGZvciByZXBs aWNhdGlvbj8KV2hhdCBsYXllciBpcyByZXNwb25zaWJsZT8KSG93IG1hbnkgcmVwbGljYXM/Cldo ZXJlIHRvIHB1dCB0aGUgcmVwbGljYXM/CjQKR29hbHMgb2YgUmVwbGljYXRpb24KUGVyc2lzdGVu Y2UK4oCiIERhdGEgcmV0YWluZWQgYWZ0ZXIgY3Jhc2ggb2YgcmVzcG9uc2libGUgcGVlcgrigKIg IlBlcm1hbmVuY2UiIGFmdGVyIHN0b3JpbmcgcGVlciBsZWF2ZXMKU2VjdXJpdHkK4oCiIERvUyBi eSByZXNwb25zaWJsZSBwZWVyCuKAoiBSb3V0aW5nIGF0dGFja3MgYWxvbmcgcGF0aCB0byByZXNw b25zaWJsZSBwZWVyCkxvYWQgQmFsYW5jaW5nCuKAoiBRdWVyaWVzIGZvciBhIHBvcHVsYXIgcmVz b3VyY2UgZGlzdHJpYnV0ZWQKYmV0d2VlbiByZXBsaWNhcwo1ClBvcHVsYXIgUmVwbGljYXRpb24g U2NoZW1lcwpOZWlnaGJvcnMK4oCiIFBlcnNpc3RlbmNlIHdpdGggbG9zcyBvZiByZXNwb25zaWJs ZSBwZWVyCuKAoiBESFQtZGVwZW5kZW50IGRlZmluaXRpb24K4oCiIFZ1bG5lcmFibGUgdG8gcm91 dGluZyBhdHRhY2tzCuKAoiBEZXBlbmRzIG9uIHJlc3BvbnNpYmxlIHBlZXIKUmFuZG9tIHJlcGxp Y2FzCuKAoiBGaXhlZCBvZmZzZXRzIG9yIHRleHQgYWRkaXRpb24gYmVmb3JlIGhhc2hpbmcK4oCi IFBhdGhzIHRvIGRpZmZlcmVudCByZXBsaWNhcyBhcmUgaW5kZXBlbmRlbnQK4oCiIEhhcmRlciB0 byByZXBsYWNlIG9uIGxvc3Mgb2YgcmVzcG9uc2libGUgcGVlcgpRdWVyeS1wYXRoCuKAoiBSZXBs aWNhcyBhZGRlZCBhbG9uZyBwYXRoIHRvIHJlc3BvbnNpYmxlIHBlZXIK4oCiIEdvb2QgZm9yIGxv YWQgYmFsYW5jaW5nCjYKV2hvIFJlcGxpY2F0ZXM/ClN0b3JpbmcgKG93bmVyKSBwZWVyCuKAoiBD YXJlcyB0aGUgbW9zdCBhYm91dCB0aGUgb3V0Y29tZQrigKIgU2hvdWxkIGJlYXIgd29yayByZXNw b25zaWJpbGl0eQrigKIgQ2FuJ3QgcmVmcmVzaCBhZnRlciBsZWF2aW5nClJlc3BvbnNpYmxlIHBl ZXIK4oCiICJSZXNwb25zaWJsZSIK4oCiIEVhc2llc3Qgc3VwcG9ydCBmb3IgInBlcm1hbmVudCIg cmVzb3VyY2VzCuKAoiBMb3cgb3ZlcmhlYWQgZm9yIG5laWdoYm9ycwrigKIgSGlnaGVyIG92ZXJo ZWFkIGZvciByYW5kb20gcmVwbGljYXMKNwpXaGF0IExheWVyIFJlcGxpY2F0ZXM/CkRIVArigKIg QXBwcm9wcmlhdGUgcmVwbGljYXRpb24gc2NoZW1lIHJlbGF0ZWQgdG8gREhUCmFsZ29yaXRobQpB cHBsaWNhdGlvbgrigKIgS25vd3MgcmVxdWlyZW1lbnRzCu+Cp1BlcnNpc3RlbmNlCu+Cp1JlbGlh YmlsaXR5Cu+Cp1BvcHVsYXJpdHkK4oCiIEtub3dzIHdoZW4gb3duZXIgaXMgcHJlc2VudArigKIg T25seSBsYXllciB0aGF0IGNhbiBnZW5lcmF0ZSBuZXcgc2lnbmF0dXJlcyAoaWYKbmVlZGVkKQo4 ClBvc3NpYmxlIFNvbHV0aW9ucz8KTm8gc2luZ2xlIGFwcHJvYWNoIHNvbHZlcyBhbGwgcHJvYmxl bXMuClByb3Bvc2FsOiBXZSBuZWVkIGJvdGgK4oCiIERIVC1sZXZlbCByZXBsaWNhdGlvbiBhbHdh eXMgYXBwcm9wcmlhdGUsIGNhbid0IGJlCmRvbmUgYnkgYXBwbGljYXRpb24tbGF5ZXIuCuKAoiBP bmx5IGFwcGxpY2F0aW9uLWxheWVyIGtub3dzIGVub3VnaCBhYm91dApyZXF1aXJlbWVudHMgdG8g anVzdGlmeS9kZWZpbmUgZnVydGhlciByZXBsaWNhdGlvbi4K4oCiIFJlc3BvbnNpYmxlIHBlZXIg bmVlZHMgdG8gbWFrZSBhcHBsaWNhdGlvbi1sYXllcgpkZWNpc2lvbnMgYWJvdXQgaXRzIHJlc291 cmNlcy4gIE5vdCBqdXN0IERIVC1sZXZlbC4K4oCiIEludGVyYWN0aW9uIGJldHdlZW4gdGhlc2Ug bGF5ZXJzIG1heSBiZSB1c2VmdWwgdG8KZGV0ZWN0IG1hbGljaW91cyBwZWVycy4K ------=_Part_10823_16284663.1196707422812 Content-Type: application/pdf; name="p2psip-70 replication.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_f9rcn72h Content-Disposition: attachment; filename="p2psip-70 replication.pdf" JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeNq10k1PwzAMBuB7foWP2wHXTuImuQ6BhMRhQCXOU7VJA/YN 4u+Tpls7mh0Q0ppWUaNHzpvWO3iCHZgy3kjxKsFpArEE+zm8whqK2wNDfQBO41A3VlzCnOxNi9Xi r5UojVhpB4TaNrZd6t5UrEKpiHgJxgnUK5hUwNLCZnbGAVsmqFZQ3DPGVagWMHqebz+W9exzuVnD YrOHqZ6+PEzHqnqDuypGvH5IY9qQcQ5e4mOHGSdjiHHOoGJyBoPhkx7thwSY2aMxuiNfF0jQaL2o E6lzoiUgS7/RPCfGGDRkG6IaAheIIzTWd1Uec2KtRaF+o036B7+IxBOVYjvynVcp2WKwOo+reuID Uug+9Og9r+JE0JV9ltk5UYl4HTBwn2WVVwmWMPRn3iZxqanUv5sKhk2ljk11hM3M2jkovR92FetC Ck3kznL9AE7Xz38KZW5kc3RyZWFtCmVuZG9iago0IDAgb2JqCjMzMgplbmRvYmoKMSAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMyAwIFIgL0NvbnRlbnRzIDIg MCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagozIDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0Yx LjAKNiAwIFIgPj4gPj4KZW5kb2JqCjggMCBvYmoKPDwgL0xlbmd0aCA5IDAgUiAvTiAzIC9BbHRl cm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNp9kk9IFFEc x7+zJUKsBWUmUvBOtgdXBu1gHYzd9W/Ktqxrpgiyzr7ZHZ2dnd7MbiUeQoguQdYxuljRSTqGBw8d Ag8RgmJdIugoGQSCl5DtNzO77ojagzfvM7//v997QF0obZp6gAF5wxbJ/ii7Oz7B6jdQhwYEQSut WGYkkRh2mWxxZO19heScm+Hj9f9dDYISAhJVgMasx9ccnvZ4wOH7tmkTTzqs5NIZYpO4TaSSMeJX xGezPp72cYZbCvEy8U3FFBQnkCIeKClZJ+YOsWxkNIPkl4m7MpaSJybfwFNnFl6Z9hDQfQU49bkm m7CA5XfApdaaLNQMXBwDVjprst2kOx+pad1SOztckRSMAnU/yuXdVqD+BbD/vFz++7pc3n9DOb4D H3WlKEqVGUnSF8Drw12N/dzgQlOYc18JUVA1nftGerza69eLR/Ulq3QSezNxVxewRPcwdgYYegy8 /AlcfQ9c+AAkGoDUdQQeobpt/sDNEyuYD4WWzdmsQ5Y7WNg5OlmEXghnsULeLNpcsEFDaW9jaV1n rqnFBLe4KPFMO/J6sdrvOdpBboyO0EnzCqjc6q2wNJNJ99DdoJ14I8N7ep13Qbyoan2DzoXQ/qSK vlGPpfOaPZjyONBt6PHhCsMoxG97MbFj2tFkNb5VGumtymfStxJ0tpD8xmxhyLFpIt/QXC415rGU msvF4hVexTh0cGgw6GuAIYl+RBGGCYECVNJoZKGRlLs2gtjC7LGWOhI+ZqTfJp9t1+ceiuTteN1B NI6FtoMITP4m/5a35CX5rfxrsaUYqmkWxJSmrD/7Q3GdzNW4FW2lJi++QnkjpNWRJWn+oCfLV6mv OtVYbKlFcnLwJ/E9X5fclymMaTfSrJup5Oos+kZ82U6aHtmuza8213JtnV6Z3AyuzR+aVeFIV/yg q8P/NTu/P/8HzbABaAplbmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKNzA2CmVuZG9iago1IDAgb2Jq ClsgL0lDQ0Jhc2VkIDggMCBSIF0KZW5kb2JqCjExIDAgb2JqCjw8IC9MZW5ndGggMTMgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42sVbTW9dtxHd81fcpQs4DIff3BRogxjIokCb uuimG0WWbaWyJOtJLfzvO8P37uXozVzWrd3aHxASHPAOh4dnDof0x+VPy8clZPxjHf7KS/FuSdEt D1fLX5fb5fsfDrBcHhbovw+XhE2lg6FjvzuCzdvPHcn13zjSx8VZHwl7/F/bfxkcxfVBUk0tlLRc flh+/3pJtePwhy/gF1/d8vrD8v0rsA5je/12eeF/s7z+dfnxNcZyjMZ8eTTLeTTmGA2kI5B+JgoH QjqP5+er+5vry4vH67vb5R+H5ceHi8MTBvDD3ZurA4VqWKj/w8RBCMdQ8adPaYEa4nmor3vqGNIE DCjGOOAv3p9jlgjOplbiwFxLTMQAoSWzYQ4Ck1y2taY8xlkkJgbbfDt+yxDmUWKqs60EFs+FwOSU LPgcVox5cSMxNdoSKxvn7wJTEtgIMfKYzTmmVhsTH+eNGKdmbzNAOMuheYZp3vrA5yVz2FK1tTWG uVwxZsWA88mmzNb0SYwDrjVboKrfMicM5GxDncYDGLB17FNXgmIQXLHehekwoQRbczunhrZ1zNff 5TySCKDunb8F73djou1svk5MuJ2NiIltGh7Tg0xkcg7XNQ7eXymYEjHZZST7XmJybNb5AbkRtIdc qs3Rz2QBiqvW53O6mucYDKeF2W6GStFUhnmUrK8145Yv03AaJNzyjGZ3kvWtNtv41G/FON7liKxn tLfPqGG+itJ/Dl09uF26hm9EVw9RLz9S7j1Ub1NkdFUwWFdsqkyqXklMcPiZ4PnCGoEpWBMqW7SH aYLYopkvSxBbtM78kCvtHpGfP8qymjJuDdrOJ/jJ/XDip4Aj1MgwcpzsMSbc9wPzZ0F82qotFhiY n2Q5jMm2BrDzrT47zC6WcJ8G5qUshwVsy5nFLNbdNId7HhzD/FMpYy5Z30Y6FfsCrjSsz2A2jCKJ kILN/FuKtKIy4MIe52V2xvHFW0h1Mi/8ixPzJDBHjFEsDoSYkVF5Oq+IixpaW9i8hEbHFm1KMI2H CJQaW697qdHZkXDWaX5ychYii+dainTGtSicYx+UmtGcrYF960KKdEUB5lNXwiH+hMY+9Ulak0an HL4tFPlxEGxX2f1veRzDJjelGB4dwObEKHZQMEix4AfD7hQ1RIbFEsYwT4oaInuyz4NhSsiYGizw jGGXEhNxWrn5GcM8safGNE1hyuha6zkzzHMMTj1xZTl8rjr38mW+hjovJ3U2kECc8y6UQw9tdo/z OsEVFYtIeGgk+Cvmd/JAg+kBT/Zmxch1R6NlfQW/hfbiZ6nOAVOYGxvnO4nBgttKR3SG/VY5qtD2 CyzivyjHkIIRwzZzo0QDDjU1whjmJ+0U4lCaI0+gkDDUVBtbnSUHcJPi3mLfepAShnKKex0mi7XQ IlhHUrhiDlLCAnrRktk419pxBrWHL+gHKWGxz306TKKyXfzA3EgJSxhObiyFin3OHk9XsZyl5wyD JPRxUF9LT+nV1qvT2mw44KEx1cEwzc7j1PteX8dRDiANFb47hJVh94rsIuErlFkO0arj6TywPXor NQxLKVZANq93mgvNWAHZer2UGoZiaEud6QFienVj1JBHGR+Q8rXkgXmvaLPzqN9NnbtZMeFsWygl J1LJ4TlchKPDaSUb5pRHjceKzCl/+H/26Z7rN/5MQr+ly4pIZ9e5gXCz0/za9Ps0pFLaEy47qkJZ MdopJjUya6GMceQezOicS4thYK4FV3FLoKjSvlgx7yZ1YMW8l80m8LZ4zzAyP7UrXfYDswiu0qm7 gmMYud8bVpSWAwzMvZRDhxwDyCpmKwXknHPbyaEZTp5jtHJB+8vPYqauFR5R0CBsmEtF5jN1QOAs z2cOHLUFF9VsGKtgkGTd8Yo8s1oA1D31g6saJlH3lOXwlaLztJcZVe80mccDN6eGUi5K/1TkIRvN yD/bOkrjr5LFDPGMhuasXGApKHW6pI0sJqfYg5RVcvKeYy6UclHLseepbK9VViHjgYlvZcXte0wz Z6F0ht3JFz71O93J18o+9fYb9UW7qkITqirb6qHhimK57PAdBxDx/F9oc51GVBhGfEeWlRVjFKHr ouprHuPIleiCWSHzb4kOvqPzCQnCiln01ofPMDB3UlS7X2sM84sUVSSzD+xTvwqiNrJrKcJsWq03 I8qAXEoppC5lLmFgHjVJxZUANs5BSiHg3upudsW81Bx4stGXWQbRgdPRFU/JK0axjwF1JYU6mzq6 NTqWMoIp0kyNj5BYPIo007krwSCY5pwx5F4B12FuFSkkZQZG5mtFCnEfxzBLMzlnajSwNH+QUoiS a2E+TOsGMysrwZSQCmCdDeMddY4iG+ZJ+kIiRqY2jErCIYQhp8lCGE8dsQR1Rp6uhImvhCLe1BEr EM3ZvL70Atb8Nz2E7mjO1VL2T0YP4QRXpDCix8LSngbmQjAjoccqjnzhijkoXWCsbcUzzJOgRkE9 SD7FWTwnKRyQK9kEPirhgMgVrb2HwGd+KXvAng5UlWHuFCUstkVgmDdaD9jTwd7oIZ+ksPdc6yyD 4NE2Nzhmx+zKXLMt1bPVOpM52sd0Aj5itA5dd5dpYHQp7PoUeZ6N5i6xwg2MIrtUSXtBfpbnsx4w nfB8nTGjW8fAMVeygVJqoIo84wYQf5JPag7NuS1cMfcTW6hijirmMIetThl/soVpwkNzsoXTeDZb OPmUr7h1GgyqXmvXXXR7H2YU81ixbc15UPVRF8w2ZRiSGQ/JpLsrU+1X0dS+jP+xptYiJPUPgqjE d5dx5ie0ohl0UKLnKhtE9vkytONrlRXyqDwyycfHKitEtk7wFH58q7IfS+nd3xw2yFtBrYrmCrdW 0D90Oqt7S32sSbgV8+JT9WaFvFf6utSyRc1ZIYrkkHdIuc9oTwG78XRVZpeJbQDry8jLhdSt1VKu EM0tovWKbAEUtQmobDnmSepOfnJDXEsHTBchAfxsQnhgxpVuU0gPJW35f9K6sNQCKrP8U3dnY65R jSQmLsN0yrXXjeesPHOa3dVOWImQROeUIr9jnpnR5gaftCZuRoFJYw1vFIXuSp8ZWeTNGQm9H+m/ VM7bqL2R7fkrXVdzrBPKnTzmWERVMo/va1bIrdYtpec1sG2ix29oVIt217XrUwvsTYpO7AG/tUHe yLcK/c6jlg2yqCY1ocZsENnjy/R6wJF0wt4alH7ZkwdEHmu3DmjZvYTozc2S/AZR3Gema9QKZj8v x9YmGp7dWI7HcLqhKadLk2tdMWMeC/CLfgjPfoSrHERpE/gYN8iNMkqO3TiU82b/2NZY9NDCjVi0 Fwz0qiCMWD7J/kRoWPlanZABYg93jKI0alO/5086X0ZftLQ84QsQ7VpsZhJL978tzJax9AuXti2j khcq91TKy/61X+mvABJbIyP9MYVbZstI56vE+KKoc3fQEPazezTQhZFhzz9Dm+wjD1D6ReZuuOie 6c1Ci5O8eMwdVuERi9Zt6F7em/0Z+YCx0DPu/X3U30b4WrdlvNl1zs8Z9W/023z5W7uTfhuu30ne dcmXUhHJi1OCFa3s6khela5y0u6NUAo4a+pMJu3C4yjO5FVdGZBFfcsAaSAUT9xLSTQrQopq6ZUE 6b1C5BqtPYh0uun4pOo73enuh7o1IBK/wjDP+w/9DcMsEkwqhVImyQfX7/HHKO+UCtD7wn6S/O2N 2v4S9grgWLjyZqK/YnMtbBDNeePpEg3tZA1X07wt4hv96VnMSeaFN2npeWNPndnxofR0CKvjbBSS 95LGjC6V58xU02DM6ELX7lSUDWKE957EUqmmhaqnzjx7u7bPf1zo0F/Opr27NYNugP5RxobgB/d/ AVUtkRkKZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iagoyODgzCmVuZG9iagoxMCAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMTIgMCBSIC9Db250ZW50cyAxMSAw IFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjEyIDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0Yx LjAKNiAwIFIgPj4gPj4KZW5kb2JqCjE1IDAgb2JqCjw8IC9MZW5ndGggMTcgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42sVYy45bNwzd6yu0dBZVROpFrgZo0aLbAAayTqcexMU8 7aRF/r7Uvb5XsiUrU2SAZoJ4ZnBAHYqHh1Re9Af9ol2Uv8bKn6gTWh281Yed/qgf9ftfjqBvjxqm r+NtxoY0gWHC/jSD1d1rI9npSyK9aGvQZ+z8q/UnJVHsFCRQYJeCvn3QP291oAknH5gANZLV2wf9 /jcwVrht7/TGvdPbv/SvW+Eys1E/zkZfslEzGwgzMH+CzXzAhUtC2887/eHr7vhl//R4vCS3XpV6 e3KQZnLyiSFoIM+X3D5OfGqki8EA+BmuBL753GA8smEmt4bcfGox7A0RwoJRmy8NJmAyyBW1jW4x gU2yxAVzfKcuMBHIWC/frJiWcyQ0XF/D5iljVI1JPhmyXOX1tYlDgCayg4K5/3MBqQXE1hnP0Y0S YxcMW65IHwpGnTDJmxQtFsyuiQPWsYneF8xzjZkSBLDeBKSK9P62jYTgJTe+UtY5EiY2oS59W1Zw AKKPWDD7p0uQAm/RVIQe2zA+JhNpeInSeCJ9lnDXlQghesNUVayTekRnHLiR6iESGagLtu9UI6Xq /v5upArkknHODSvKcjVYy/lmkmrPNt7eYRvbCHIt37MNVWzjBB/axoK5bhtqxYxsY8GMbEMwqumK 2RJQmoJzVyxxdh3bYONTjAtGdTApeOOi9SXOocWwk5JarjlfaoMwGOFU3c/+2NqGZUMp+ovkz3yM veiHmEaEpCGM9KDvJK+KtXiRGVaYls9kLS6kgnlubAwgssgOCuapYz7OG8CqqI8d82EWxdKQj3Ax rj5r/0fHfLy0sq8Su++0YXBk2KeRzCAkkNpXcr3r+IZMg5T8MPsYycRARa6HjrXYZMK5hFqMDANG LHLtxUkkfHAke3EeJ3xiXVXV2hSZUN9hZ6agldmcN7XznlfnGHLSiFXp255H0ZCUvkq+zJRVr4g2 GqoPa6cKyt4oQ67K7KbaydQbmWteO19lrlKM/2KuJ/jQXBfMyFwXzMhcF8zIXAUzqfW+PSwGawLk BXAJ9K11RVEQSS8umK67JukepFjiHLpLWUiMNenGXb1sAYxVnJ67Yjaq3PNn2Z+7a4TcqjAiBFL5 uVcXTM9dpayuJt1zV8zZV9XouavsJbE+q+euIW+klTo67uqkVV1KQz5O3n2pPqvrrrK45e5aQV13 DXIaVOW4+R/fRuSbd+Tv7dNIvBWDKHpGq849y0A1MoF4Cbj5p4VItRzRimgFFtDKMwRWVpuHtrkg yUrr0wr51MgrP3goUonSemF+76SAboV8a0RB4qiWApzTPW8sGZOeq4OadlCU8kzmEqXVw7SzOCz3 8txrqmSmcCdI9xEj/8jyQ+3NVBC5GpABKBB1ReeiH+nfktN1cS5DQv24OMuQULU4g2xpr3+3n9Bl RKhmRCyQ3fVX+wI5NIoIThzJiY9ejxJYDAli4dKIRkUnycg6t0LaSRSjWJZ3foW07SZzwTgZ6Orq QVqezyZ5W7i0ulr3boGoK69+znIgHNCVrUs2L4hV0pcjSMaqvP3CKAhJR3rygyqCDWiiw8H9Tz0Q zqi0/yPg86LI/UKXuZJodE6eKjF6df1up6ESfInS7VmPeUnktQCdnpXhJUOuaPfYmyhg2JWsb6YC zD37L6yjRbMKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iagoxMjM5CmVuZG9iagoxNCAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMTYgMCBSIC9Db250ZW50cyAx NSAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjE2IDAgb2JqCjw8IC9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwg L0YxLjAKNiAwIFIgPj4gPj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9MZW5ndGggMjEgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42s2XTXPaMBCG7/oVe6SHqvr+uKZflx6ahJlechFG JG6JTWzTTv59ZRtsg1xCExoKzGhgnpFerXffXR7gEh6Aq/DBJLwUaEZACgKFh2+Qwbv3JYWkBNq8 y6RmpW5g2rBvWxgtjt2JNO+w0wMQzETNtj9131DYhTSbSCMt1xKSe7iYgjQNFxamKQNmCEzv4d0n iknQNl3ARLyB6Xf4OA1aWjXo5WpgXw1q1VDZgvVqmAVGudzX8zl3yxLyBVz51TJNXJXm2UAiOlHA 6ouOBYxS3UoMK5MSqBF2X+LXRs+ARJwzbGhPT/w+AtxqrKwxPVNEjAj3ksJy1DFlzFiBjWG03yeN IaktplywBkI1VEWMojQcptUh0SqkreBUbBk0ySJGC4o5lazfJ4kZa7ES2g7PQrtp9w+LgG7AehUk PCVNWPtMWfdMb5iQr5lmQ0nWDiT1afbBVS6cWLk083Nwi8oXkBSuvKuro/DlKs/KdLb0sPK+OGc4 ZbCX/yycnaQ+nDecsR2vQ6eSNO51A0mSs1FJGyMZktZg218ATXxx7zKfJX7fpp8lHR2WPhJNSv4c Tn6mpKOU81FNMIwnalEV3El39KQto7LKizS7bSoHlt799OXB+KLTpEa4CxrrMdyK/atcxw1k22M2 9MZCx3vMlomtWMhwL05Vz6xrBu20D0awpZL3TNyrpLRYK2l7Ju16DOp7jMHEmsFhj3+bx+h5cR4x KkSZUE8Y1ZFpjE4iqa6sIAnt+35+DbPH2OGPUIlenqAblWjH4emTDfNA4NCJJDVh7wJH44Z5la+r uqpdVbnkRwlumdc17qo7qPKzdsy9grc8sq4v8UxJbRj0ArmhJ3lsCUaEGgwj3BZxcbmLMHlJKtAW mceVTAWWPAxwWwRiRChshWkOasbJi3hUZLUWfkiLMs0U2N1/snSRhWlDsJCk3yYeOI2QmHMhOiSJ fMcSjpXS/ZXSeBsbBmmhCe+Y23MNLKHCtCXHFBh6nXmlLrBOUZ+jl2tfpL6ERV6Ag1W+Wi9dUddV vi4SD/O0rIp0tq78/FzTaNCtdKR75qtf3mfhzOYfZTlQ9xsy1W1pCmVuZHN0cmVhbQplbmRvYmoK MjEgMCBvYmoKODExCmVuZG9iagoxOCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBS IC9SZXNvdXJjZXMgMjAgMCBSIC9Db250ZW50cyAxOSAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYx Ml0gPj4KZW5kb2JqCjIwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNw YWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0YyLjAKMjIgMCBSIC9GMS4wIDYgMCBSID4+ ID4+CmVuZG9iagoyNCAwIG9iago8PCAvTGVuZ3RoIDI2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeNrNl01vm0AQhu/7K+boHLJlv1j22o80p6pJrfbSC4YlprWBAFbTf98B2wvx WonVpDVxJGT70fhldmbe4R5u4B5EiP80wL8QNA9AyQBqC9+ggDfvGgZJA6x/NUnHKt3DrGcvtzDJ To0U9C+MdA8B5bJjtx+5dwSjBH0QFSkjtIJkDW/noKKewwvXjAOPApiv4c0VowFqm2cwUxcw/wEf 5qhlq4a8XA0cqiFbNUxtwe6qWAicCXWo53NZbVZxDbe2WuVJ3OZlAV+SpV3bplNKRkr/Yd4Y01ul eOVKAYtCdqj0U5+5EUmEMJQrzhw+s4cMyEBSvG0zMPmdDxlJjTCMOGjpMUoZGnE+CrTwmJBLqoNQ 9wzpmNJnIkOVCYZ7nNUeo3lEpXT3RWbNYdX85VmQp6pmfxa7Q+uustOp+a5quDuL71yqC/Iqkk4q j7EkY0aSRoVs6yZvWlskFn7l7RJWZdNAmaGKpiqLJl+sLFTW1ufS3aUSvzyayuF0yStJ6ibLSal0 koZUvr+eX6a2skVqixZSm+VF3g2Gc2ZO7gfCdDIn/Rn1dbMqbB13pdaWUJebNi/uIG7bOPnZnDN9 QgRTS5+TNCq8vuiwa4uzdu2hGTHfxm+fMKMdPoufMKM9U/hMaGjAjCaOSX0vEoKaQAzSjviMMhHV kZY903vR2vcio6hBwxriwFEvEpHcI+SYXYWaciFHYXwfjgSn+LUYmKo/0keM0XgcnA8MriReJCwg TZmW40QTj9FY6EoPzMkOSl6wdz0udeK6L5Dyme57vqbJa0jadx8ZJA01fZU/2BQdM2tsiz1YQ2sf WojTtB/+sLBZiXqWcbPEoea0k/8+zAxu1tOaZU7RaB2J22XTmUCaZ5mtOyOttyt2AzEKyQvnsGf0 BR1NzRa0P2uv4zq1dW+omMEY9zusxilsdwc+EfqGduPbhFRUy5Dv6dnGdwAW0FA44MgzjVZUMRGR PeKPZMUkFaEcovz2ERyRodGsQ3p/uPT9gTGqpA5dlMpH8ElbCiYd4g9jLRkVTA233PoOogVFoxl+ aLkrQXKGpsCnwYk1hVM0WkDcMElTnNrxqsRFs8Khs+2TyTzyiHBqw9opGpL5sSxTQHfDqRKnsIhX cZF0Hjek7Q9EiRFkCmVuZHN0cmVhbQplbmRvYmoKMjYgMCBvYmoKODU1CmVuZG9iagoyMyAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDcgMCBSIC9SZXNvdXJjZXMgMjUgMCBSIC9Db250ZW50 cyAyNCAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjI1IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQg PDwgL0YyLjAKMjIgMCBSIC9GMS4wIDYgMCBSID4+ID4+CmVuZG9iagoyOCAwIG9iago8PCAvTGVu Z3RoIDMwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNrNWsFuHDcSvfMr+igf wpBFskieAiTIYg+5rFdALr7Y8tjWrizJlpxg/34fu6dJzrCmIyeTKHEAwcZDsVhVfPWqWp+mf02f Jsf4Xxv8x1MkMwVvps+76efpdvr2hwc7XT1Mdv7zcFWwIc5gO2O/WcDq3VMtmfkPLH2ajCZfsMs/ 1b8pWDGzkZBCdjFMVx+n7y+nkGYcflC0NFEy0+XH6dt/WG3g2+W76YJfTJf/mX68hC+LN+qPezMd e6MWb2xYgOVndm4i68KxPz9/uJte7u5vrq9eP+4evvsrvYNHs3fFsxAmm5w/9u7fsz890nmns7N+ hivALx5HTDI6x+CqyYu7AeND0JZSxaiLzyMmZx0o5WbnesAEytoG2yC3L9QRhI3TzvgGeT9Y4Ri1 D9ydNBWM6jHReh2M6TCvLgZDMSSdjQ3C1dWKSc5pE3zn0K+DnYxrOU/c36ti1IKxBhfzuTtrN9ix BjdjnxrmIMzzBa0l0sb3F3sxGrLMCNFRgHqIsjT7093rfjRDsz+86bMLVsec1RbGU9A50PG9uqdz QDPqPE8HNKPK07Fx8QQ/vUFQmO3ydKg+nVfkw6ZL5TWrs7g0LS6p6lLOnUvtNf+whLFzPiSnKZCt 8IvXS913GFSPRkqaybWEekxinRP7htmtmOpVRFZTNNQwD4OdZHFRQ91ZU8OoPcaTZsuuYR5HOzFo mEkN86HHzPfLLutsEc7R52oHT8yjFKPoz4JR1rioyXYx/Djasc5rl7v43AkY0B3FpDbiYyng+fRn PQqYjAKh5Swl+ownhCfvXTrK+xEmRe1abaiLNyPGB0LCwua9go3apC6nXxaKPsAki5axmVPLIGCX +CgX6hDjWadtKxFRtk6ojFqpNnqvTZ91oTKSAdMnu1WpNnn7m1nPhkvW++gcV6rN0WrLtHUvKs0g xC4TV0OlkmFE2aQtf8gSo+Jpq5qJyJUGr47is8V0TyFf9VSmOyRfn51IvuoMLj1Ndh64VMi3ujRI qS4dRSQn2y5wyFF77rWac0oNM2YsooBCIlYV82XEoIA8F35eMTdvR9JkvGXOi0MniCNlr7mottXO yAk5QLUxV5+VyKvkoSZssyPwDzhDO9f5/HnkDUhIbVMXQ4HrLBsdchfDX0feILz41PsjvFRnso6H /gzM4dAsQ+/PfwXORMKyTaLPK3N4V+5uhbM6O7HcnRpmNzJHgFw33Pkj9BQ2haU6f+7HHsdQf9Sf JcQnusJS3DC3AibjEQa15U4Khea7o66FvpM9xofErVSvb64lUsSU4UJstv73nCrRUfi7qcTq0tNU 4h6+qRJXzO1X9QT1R+/VuM5iFBHu9Qr/9vVtSp3FJbfERR259CgQNaFgqRWLxMFFk3LI9ZYCOSS8 e4hk3+yMJAwlUAZaqq5dvBsx3uxF8umzMhRVRKdaMTLhg2DnOXS1I7x8dIVFUq2YDwLhc9SJN+OD OdQskup0uULlhEVSrZh3kpCOi6RaMY8C4WNQzylvxdlCAmLyITGGjfCdjuQ274UOrg9ycSMxfkB3 cfno8keMTxjF+sN+ERg/GW1Dd9i1ROcR5dE/+vcnX5j68xdYmFiOH/3LcTmFMZRSqTLAlbxdKMsF 7221uBbrwW6KtDWxYpSw7AilaXKzMm7BGM/Ll2FkhdzKaycuMT7tTMT0RM52mOtx64TRGq21u9Sb wU5KGJtNbJCbYVmU4Q5T7syM4YNg1bF08BUi7IoMQpz64Ai7IoOBGOSydRSq0ONNkNrCEHoTpVYg z7oryvx3EwHVo4NeSU/rlepMHlUmDMiR4NHLcTbCEIoyiitaWDlximUtVYMuNJ3oWePlUIXcD5Sa LF6XcRVxJ6ybEJrE1XFB+c6NFKOaOu1KRrk749pBkvA1GbSMHACjuhbw14/e1oJD5dJxzzV643mV Zd3281Jn8qh8nXnKMqB61GL04yixl12A2oOFpl1XAStEqGXoHuMsF8gyFI1iJKJ+kvNxw0zyGdIo rrFU0n4VDSckUy8nqBWoRp2z991BahCOELuEHrpCvgj1vl+urpD7UYIV2WhyGCG9auS5k6yQu1E3 oX9CWFKFCAM3Qe1guqiQx1E14f1qaMuNuKAjBR1aWATd6aBxc3BK9HaVi4Q0xi1vfUTBLPXSLXOe gSiC8dIjmHvM8xBFWYtILkmLDwxJybXi2kkbZUh3m7dyES1hkqgJ/SitkzFEhVZbgmpPkDq85Fyd WK+UbxplUD/tLZUvGr5lZP1eegDhXCTyUZ0/IU3qTFJg/yYJL/tE5bhnWi6Q9aQElyZhkY50lf54 uiyIwJHJstpIF+ZYvUXW5ECQxlEla2Gl743FEM8bNEtltEyHrh7MyxRM0BxaZV2NNgKD8ZMbi69S NTHhNfHxfb6CANR50giloDDF/C4h/uesiIpSgEfHG6KfRqWAKKcEkbz3X0h4iXLkyOsV198vOFyS aWNzrFYmQRljCC476L1bku7FTAm9kauVX4SPCkmz7w7ajTLAOR3Kon+FSCsmKIXUEMI3u1kocOrO EfdLNlCFvB5VQFkvGdD9CnkrqABXXlM+HTkFAeC1K+P9HiLullhj9tjIImQAGrhTp6NiUV7ap40c Ljohr4FTUs9AcnSMcStwgUmXT30r5Pr9uJjj4LRnIUV9F0zadf6+Eb68llWzo62wpLJptixXy5LF VH4dgRvk4fdIH3UWmpk8G3UWmpl9OgfNwKNSCz3N/PP0zn9BzzkfeAYdzoRAasWMOY8uzdvIFbET ttngM6K0uiUus1F+sSzd9lYm+Rc+SmdZIXcCzZRt0pKRE2SVcyoTOI3udjwD/oUUq5DPMs8YlyYx LKoNJF10dzLPpM7d1wLPgEQ4tei+lUkkxK3QWZdL3+aaRYGtPLH2XWwFEilbVbeRRBuc0db5LU8K zwTfx1ad+lh5MipT/Va5Qm4Fmpk/VYatwM1fKn2WL72nGTY6d2UpyPocFrI6eWllMyby4DbqqfxC lO7KSRL12aP5+ZrCe0GOBkz1vlm5uRYkHEH5L+Wv5OBCbvp5Gbaa6an1/5T4DfoKZW5kc3RyZWFt CmVuZG9iagozMCAwIG9iagoyMjg1CmVuZG9iagoyNyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDcgMCBSIC9SZXNvdXJjZXMgMjkgMCBSIC9Db250ZW50cyAyOCAwIFIgL01lZGlhQm94Clsw IDAgNzkyIDYxMl0gPj4KZW5kb2JqCjI5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0YyLjAKMjIgMCBSIC9GMS4w IDYgMCBSID4+ID4+CmVuZG9iagozMiAwIG9iago8PCAvTGVuZ3RoIDM0IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeNrNl01vGzcQhu/8FdObfChDDr9PRdIkCNACbQMBufiiymt7 C3kla9cw/O87+yFySyp2iqpyLAMLyw+GL2ef5ZL38Afcg7L0ywX9WHAowGgB+wq+QANvfm4lrFuQ w6dd96xxAywH9scRZtffWkkMH6p0D4Kj7tnxq/gXoypiKGK8CcoZWN/BuyUYP3B0QScR0AtY3sGb j5ILyra8hoW7gOVf8GFJWcY07L+ngTwNG9NIM4L91QkNKJXJ83y5XXXw6+qp2sPnarep16uuan+K Idn/3jIp3RiSrmgMSK9DHvL9kGdGMqUCR4My4otPOQMaFTdCY2KWefPjvNjpmz+B/VULmpcTOM4L 47wuUZuvRupbzU4TiVrN8kghzCKlVr/d7fbb3b4mDWjgUYh629B4t9Vd/9WG/nMF3Rbef1pesGey n1iTPLvxRfbV5ma7r7vbu6mn7By5cn219EVPj+iL3MtEL3aFvSo4boP3zzHaIqc+WBYZul8FZRxy Z3QqtCoQq2gw5cbBWM90JeNo/oZWtVin3haQs4J7o+NgbNE8K/i33wz2guBHnzl04ugz94rexkjJ j1+a7WNLQ94/1Ht6yJquPWNArwaOLqbXV2o7xlNcTvF+OOMrK6WxSszSpGb9PqSZcd70zwBGeFEN 3UuEU5IHdC4R+6yGM4Fb52Ui2olgE+GF5Er3Xh+IOqvhZSDzPZY1JoJ5K7nBeY0ur+E15bBhPpd/ EoHmIhANi0STE85xZX0qsc4AKSipUDEGmwY5zyOa6SbwuG7s3PIPusU0SbfPuW5BcEk2sANc3CJH cQ0aG8stNoVuhm5A0AeCFTI5R1sXozDVWB3TbXg9HIg/h77NCGtp+lonoj6imxuUPZa0LxWE4ujw 6yUCSu5I+0TkTgeteVAeU8OeTqIbe3HLU+oWxHdkWwzz8trGJnaxLVyblrYDsCtE8nQDlYrAQ7Y4 eqQlR/oQgVxWr6lZCtMQyUQ2WRS4dj4Nka+uQTqO6G0EComU4U6jjtMsHDKeZNcp5MsKsZPsmqc3 OJtvKpx1/3ofHz1iJ0o0NP+wp4iJ8i3F423VwPaxocNd3cJuX7W0uXjFM5BF9Z0dgWKi1Lrfms0T bIYTcdcfjterBm4q6mF/JGqqR2jrm2bVPVA34XJRX7/iZtKIIn1TVVfV1eXF7Aj0N2D1sc4KZW5k c3RyZWFtCmVuZG9iagozNCAwIG9iago4ODcKZW5kb2JqCjMxIDAgb2JqCjw8IC9UeXBlIC9QYWdl IC9QYXJlbnQgMzcgMCBSIC9SZXNvdXJjZXMgMzMgMCBSIC9Db250ZW50cyAzMiAwIFIgL01lZGlh Qm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjMzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNSAwIFIgPj4gL0ZvbnQgPDwgL0YyLjAKMjIgMCBS IC9GMS4wIDYgMCBSIC9GMy4xIDM2IDAgUiA+PiA+PgplbmRvYmoKMzkgMCBvYmoKPDwgL0xlbmd0 aCA0MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnjazZdLb9tGEMfv+ynmqAD1 et+PXgr0hfaSvgTkkgslrWImFCmTVAx9+w5JiaS0NOsmRlXLACH7j9n/zvxmuPsIf8AjSIO/lOGP ASsYaMWgDPAOcrj/oeKwroC3n2rdaLVtxbzV3nVisn1pJNZ+MNIjMCpUo+3+1H8jGIW1QbTTXloN 6x18vwTtWh0+hOUChGOw3MH9z5wy9LbcwsK9geVH+GmJXjo35OvdwLUb0rnhuhM2T6c0CC71tZ/f i6pKV1mAv4rsUKdFXn134ZC8Sr6edcht5xCfQmvgTvlrh29bP2OllJ4KLXgrJyhfFJFGMUVxu74P uYBYgxvTysuzhiyqWOMVde60VhsnzSMRbooap8Ug+vCGXGmMZlSbkZ8sRHGs4lRaIa5MkwuNldQ6 bQZNEsVx0lFjvBo0+7OGnDWeSaq1FBOaPo43jippB0k5lrS2OGOWCucGTVwLzqyg3PIZyxhLWspG CCzWcRzuNZXjtR5ijTBInRVkpu5ceNHUa4gT1x3ZQQS5m2OMK66pZ6MUZp9jkWaMcq0GyMKExmjK pJs1ZISk41pAhBg3WiMbag4Njj2MbIyWyrKJSA7bx8+ywZ3x1DF5BccFq9wzBFGrWTg8Aq3He19F rArMDVXjvphoHoFlpUKMqrobNOSkEcJQxWYTLYRTFDtx0NBbTkTjeDSzJyaioI73anLZqJ3Ecqz7 KOLU0OwH4lmzj9DQjONMkHwujjaGSt4Mu7OmitgwQlGjvB00MazGeURDqkGTfRvBYZWlzhgxiOKO t64ZCt4MmncRG84zKr0abSxmzGODCWv9M2u1G/TOUuP5KIn5xETUgmqrZ9bCWNxSpf2cH86doFKN 1tpMTDtMkBAY8Pn8cEwOVmMIs5oYiEpRLTrNswOR+a69znHqCQ2+5NoX6pnVh+sj0Re2F5lrr9MB jZ/6sHkqhvlHvLr2En17vRdKt9h/vaWXnBkvLHk/sjR0/I+/LO+y8DlkuOw+S9dJc1KDJHtKjhUk +31Z7Ms0qcM3sE7yG3kXmvNJ8++l0H2JyX/sqRkeE55OXHZS0kkNp94PW1jAKvxbMskXDP5pDAge LtS1602RB1gdm4qfIbjLkmMo6axR8jpvKDRKplpIWDbZQv+UO/Iqlk65Ixct1Fsacvdbnk0kDj7l xVMFIS8OHx4gWRWH+pat39zUrnyX4fGQlmEX8rqCuoCPh6pOt8f7TdimSMP2UNYPuI/RXKC32kED Q7PKPAzklSw1d+cXJbW3NCT1z1Dt8arbXnz3AdOXh7Bp07tLPoUYkxsy4VzkfhPWadVc1TtgIUUy ylAVh3IdKgrwtqhbTKB/bdwSCavk/4yI3tGQ0l/zOpTJun2trkL9FEIO2FdVgLb+FXJxxH/AoQrb Q4ag3JAIvAjGRNRhXaNJxDYtDlULdTWu+t/cuTVYCmVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoK MTA3MwplbmRvYmoKMzggMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzNyAwIFIgL1Jlc291 cmNlcyA0MCAwIFIgL0NvbnRlbnRzIDM5IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+Pgpl bmRvYmoKNDAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA1IDAgUiA+PiAvRm9udCA8PCAvRjIuMAoyMiAwIFIgL0YxLjAgNiAwIFIgPj4gPj4KZW5k b2JqCjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgNDIgMCBSIC9Db3VudCA2IC9LaWRz IFsgMSAwIFIgMTAgMCBSIDE0IDAgUgoxOCAwIFIgMjMgMCBSIDI3IDAgUiBdID4+CmVuZG9iagoz NyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA0MiAwIFIgL0NvdW50IDIgL0tpZHMgWyAz MSAwIFIgMzggMCBSIF0gPj4KZW5kb2JqCjQyIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFC b3ggWzAgMCA3OTIgNjEyXSAvQ291bnQgOCAvS2lkcyBbIDcgMCBSIDM3IDAgUgpdID4+CmVuZG9i ago0MyAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgNDIgMCBSID4+CmVuZG9iago0NCAw IG9iago8PCAvTGVuZ3RoIDQ1IDAgUiAvTGVuZ3RoMSA0NDY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp42q1We3QU1Rn/7p19JTBkgygBEmbWISEhm2xCMIKEZAKzkSQiIUTdFQ/skgSS aAxImhoqGFEQFikUFXzgs74KWCZL5GzAB1WstkDltKW+qvYRpafKqW1BWymZ/u5swMfhj/7R+c7c 73m/1707+xEjouHUQxLpje3RZeShVyA5gjejsatTfbiiYhroASJH5pJlS9v55n+1EzkhcuQsval7 SfXy7W8RpeRCYLY0R5s++5U+H/w74EtbIBg+PrWTKNULfkJLe+etnvtoIfgp4D03dTRGKUSl4MvA u9qjty7zTHe/C94Ar94cbW8Obd14GHyT2L+sY0Wn9Tk1g18PPmfZLc3LSn8xZzd4E9tF3oxEPaIi F16ip4XE2UncWUtZeDOk7XQRkfVnvCfx/nVwJqqBbvAl63fSeOzoEy8frCijHMqkVfQAOrOKPqTL aDTl0p9ZOfg+OkYf0VV0PR2iGtrFrqQYXU3TqJ3NoAns16goSI/Sy9jRTR2wraIfkQ+79luvQlZK uyhBX1AKZdEM1H893UMPWofocfoLnbaesP5KJbQWFsetP1EAJ3MPcRpL2fDZRstYAe+07qZyxHuA 9tOH7BKrnC6mKVRGBi2lFmqnm+ku6F6i4/Q2y0Q1BVSEOFV0HW2ke2k7mfRzprAfsEccKVaL1UbX IoM27NuKao7RCfo7S2evsDesTKvPshBbo6k009bvoEfoCXpSVEJvAAboJJvPrpM0aYolW5OtM7BP Q9d0qqUbsKOdbkMlD9DrdBjwEaLmslJ2DVvGeliMvcFnShc53M6rrTXiNqDfMwBzkf8KZLqF7kcP n6PnAa/Rb9D5FKbxSt7DT0npku6Y5+yybrf2WC9bb+FEnDQC/a8FXEWddCutpw3Idyvto1fpHZzV 53SWuZmXjUYOfewD9iknns7z4O2XUocUk/Y4yLHD8YGz3Hn34DODA9ZS637rsPUvVM/Jjd7n0uWA qYhRQfNoPoWpCb2+0b4fD9Ie6qV+9O44vUcf0FkaZONR5+VsJruerWQ/ZofYEfYl59zLFcTM43fz xwAH+RF+XBorZUm5UrG0UNomPSY957jX2eRc7rzP2ev61L1+sHGwabBr8LbBF61aa7u12zqIbHzI RpzpbKpGtfOoASe4hFbavY6Ju4R89tILgH3I6gC9iF/zMfojncKd+w/6kGL3IQOdKGLTWBkrR56z mMGqWS2byxpwPtexEIuyNraKrWZ3sR2AR9gTqKMP0M8OsMPsGHsbMMA+A3zJndzNM7jGc7jOawHX AaK8kbfwVt7ONwGe4Xt4H09IJJVLVVIUYEoHpePS29JH0r8dYx2djh84fuY44njPMeD4h+MLp9dZ 5LzGea0rwzXN1eV6yrXXfaP7efd7FEePf4qavvk0Ujffxr+i1fxK/M7eJOK/5LNxEqvYXvYUOvU0 7u0UwO8BOqAYkApYgx5O0ifmZE/QLvWpyviszHFjx2SMvuTiUReNTPemjZCHD0tN8bhdTofEGfmD WlVENXMipiNHmz27QPBaFILoNwQRU4Wo6ts2phqxzdRvW+qwXPIdSz1pqZ+3ZF61jMoK/GpQU82j hqYm2PXzQqA3GVpYNU/a9Byb3mLTMmifDxvUYEaLoZosogbNqq6WWDBiwF2/joalFvhxMdCJYcKx SbOiq1oygIRF0ByrGUFzjGbYOik7GG0y6+aFgsY4ny9c4DfZrEZtsUnaTDMtf2i72KfCtD6E2AX+ VpE/bRzepDVtTOi0OCKo6A0hU4qGTR4RMdLzzdGaYY5e+XHG1+w5KnjPN5Qmz66KNseq0JqNs5Ns RHDRe8DVzlfhlq8Nh0y2NpxMws49WUWzFhSSSJtqpmgztZZYWwQ9p/pQfKw+NqhFjbBJdaH4GH2M zRT4+zNWT/ehKf0FlQWVAk/3ZaxO4hN3JuW/PjjMtjv0B+Da+vN9YSKSVo00TbXRDqIh16liaZ5K scapMMMTZqiy1UyZFYl5r8Au05nt1dTYacJBaSc/+7YkOiRxZXtPkyDFcZ6/EdAP0Qma6K9NUEpd qJexH4YTzFqbICOrH/8w0qKFUOeK69BqYDeYPD8Ek3ygJvnVKmRdJc5Njamx6qaYWqW24MAd2TaG ojkWDqCc+aFWrA0hn6mHx50nm8PhK+AnX/hx2H5iYXhoG/LQZnuAg7Mw8vtr0aKcutC8kNljjDN1 I4yW4P4crAuZB9HFcBhWBeczBV7VmjGUcyFyLpgEIpD0Mh8+4CIciyU5zWcejMXGxcTvIMknGH1X oA8JEmQ7wFVJsJ46W9Wj+cYJgebTfEgrbCBUEa7XuePFj4bju0vO7ZgVJHyDZ/VxVu10Jdi1eiY5 3NUSpTod1ZLEx6a43NWMxnhSPvVV1Wfk5199qmzO2bKrvV+UzfGeLaOKsrNl3lNYiotK0n3pE/H6 nF2JM185a796ISG9/59se4qZwdbwNdJhGkYZ/eRkp+LDZE+CnerlwwO/PXuEAieLi0bmXDaltGQy Plcu7cTOXd3dz+38Pluze2X3zp3dK3cPzUHUrxfKi9LKTrN0j82/1n3GeR6fqwgD2zl7gV00CEJ+ fTAyuNt94Lzm3MOdb5CPH8V/NWY8zC/2HvRnOd5t8MTJCygmcv8FM5nD1jIaOeTHBYqMylBwbnV+ Q2t784qC+o726M3YZT9Ws5jvLvAI/d2EsWhivp6W8lYDS2tgFcfy2GMNTK+U2Rm4L7JX1V699krs jD5MiLa42RYX+7xyLhf5/I1LWA9yMS2azCIT1Cvcg5PdA2oPKE6PcfEK6naEvp0L7KHNoDeD7uFO YA9uQgckHZB0QNIBiYMWgatDhEW2x7ngRNS5NlcErgJckc0FEC0ALmBzCvfEmUffzz5mc1j9C2nK q8tHKC/iT3kOLSaFFcfXzVVeZs+QSjLbbK9r9BGq/KEqv6fKm1X5dlV+mW2kOihuslemj6iT36mT Z9XJFXXyFXXyATYds4PMJH1UrvxSrpzIlZ/NlW/Llbty5YJc7O7FOCuzZ+31Pl2tkb+skd+skR+o kdfWyCtr5CU1sq9GXpwpT8iUx2XKCbZ6X9rWtC1plAKyb4u8dQtkp/cWB5TKBPvnCyVKvr9USbAN 8QY/0J3xhl1K5cXsDspzMFTUQ3lc4NvIsHE3K7LxrazI1n8/HsjDthXx8keBlsfLB9COG6nQVrbF SwYgnRpvWKhUprCSIZ+TyfAIXBAvvxfqSXH/UaUynU2kQpYN8QQqsdUaldjmlw5hV7whB+bOPiRq 5SUYiyuD6xOc7VPOBOqVLwoTDkhOFyY8QH/MS/BdceWDAJA+Wnk/sFB5t7xGOQQPrzUMKK8EblL2 ++0NPzFeFN7pOUxaD+nDlKcD9ypPBTYoT5bb6sdLbH/bGmx0fx6E+5QNcLOiEB+WuHJLiYgwTLkR Htv8tUojxA/paUqh/3JlfuCAMi9wizI3GanasNHswH67nH/qcmWWUhnIUmaUH1WmG6gkrkwT2+PK lGTwyYV2ecXlVyn5KM+xT5nUUKxcipBML1CuWepe5L7Gfbn7MneRO8ed7R7vznKP8oz0eD0jPMM9 qR6Px+VxeHBvPaMS1h/0fPETH+XyCuRyiNVh014uVp78RnDm4bha4v/JZJsu6arIqBhZnj6tyrjA Ehla8y/0ZJnb8G02d2aFzcmCsLLCteZlYhjoZyfYx0Gjn30iUBi8j50I1ttynxEOZ9SaV9WFEuyT YGsCilbMWkL5CQSYKWBQa15r+6E8iIx+ahAIfngp5Qk/uLKlttmGpFkAXmBmCCTMBihgmwX4gG12 VJj1rs8LGr15ebaJs5DW2ybrnYXCBA1PZl6ErUZvIGBbpZqsyM67KNW0HWXZjkpKYFJeIkx6J5fA oLdksq0OfK32J9X1SXW9rV7wtbowqX48qX4c6vz/09M883+z27vg4Tt2iOksogWb8UbMjV0YQHsW q2rvHQ8PjW05kcWNLQJHm82HtWbDvEMz1N4FOy6g3iHUCzSjl3YEG0K9O/RmI75AX2APdXvXbVoe /FasDedjLd90AWebhLPlIta64AXUQaFeJ2IFRaygiLVOX2fHErUFW+fPXHGBp/N731u4YsVC+i82 Ro9hCmVuZHN0cmVhbQplbmRvYmoKNDUgMCBvYmoKMzA3MAplbmRvYmoKNDYgMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgNzUwIC9DYXBIZWlnaHQgNjY5IC9EZXNjZW50IC0y NTAgL0ZsYWdzCjMyIC9Gb250QkJveCBbIC0yMDQgLTQyOSAxNzAxIDEyNzIgXSAvRm9udE5hbWUg L0RBWEVPSStUaW1lcy1Sb21hbgovSXRhbGljQW5nbGUgMCAvU3RlbVYgMCAvTWF4V2lkdGggMTcy MSAvWEhlaWdodCA0NTQgL0ZvbnRGaWxlMiA0NCAwIFIKPj4KZW5kb2JqCjQ3IDAgb2JqClsgMzUw IF0KZW5kb2JqCjIyIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFz ZUZvbnQgL0RBWEVPSStUaW1lcy1Sb21hbiAvRm9udERlc2NyaXB0b3IKNDYgMCBSIC9XaWR0aHMg NDcgMCBSIC9GaXJzdENoYXIgMTY1IC9MYXN0Q2hhciAxNjUgL0VuY29kaW5nIC9NYWNSb21hbkVu Y29kaW5nCj4+CmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDQ5IDAgUiAvTGVuZ3RoMSAzMzcw MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNq0vQl4VEXWP1xVd799u/v2vqbTnU53 lg5rwtIQzUU22UEWCdISZAcRAojgGhQBERWdcR0V3HFBAgQMiK8Zh9FxYWBcRx2FmcF1jPLOMIwD pPt/qm53CPr+v2/e53u+NPfeuntVnXN+Z6lTF4QRQhpqQhwyZi2eufTy6/TH4Mg7CGHnrJUrovct fXcllI8hJPacu3Te4qlP/PcghGQdIeEP865cPXfxNT+oCFmPIzTvnflzZs7+Z+2o0whd3QzP6Dsf DjgXa7+D/a9hv3T+4hWrqu4ITUJopQbP9F+5ZNbMxAc2L0LXlML5OxfPXLWU/612L+y3wH70qpmL 53xWdFUG9t+n+0uXLF8hLZODsH8S9l9cumzO0kuyB79BaNWTCKk5OIYRbQ9tEcIi+n/9w/kt4RDi BVGSFdWiWW12HTngqNOF3B6vzx8IhsKoKFIcjZXESxPJsvKKzgdUpqq6de/Rs1fv6po+ffv1Tw8Y WHvBhXXGoIvQ/09/g4egof+b64X9KABLUHgGBfgk8iOU+wqWr+k2uyD3NT1Pt+RbuLg1vyC0DW3H C9B29Cp6DZ+Au3agfagF/Q750BD0MLoe/RKtRyKaBkduQ5fAT4Djv8SBXAvqgR4DXnoMHYJrL0U3 ov3Ii/25b9BN6FbuPbjrVmRFJWgQGo+WoDvw6NzVaDo6yt+C+qHR6Cq0FDflpubuzN2TexI9hfZx v8t1IAsKolnwO5T7Xvhj7k+oG9xxL3oQHcX3KHuQAW9pgisfQcvQQ1yGx7l5udNQgxi6BurAozHo EG4jKXj6HPQV9uPrucHwlCdyzbmDcFUYZdB89BDaj/vg4SQmTM+NyR1CXnjHKnjqg2gX2gu/VvQK +gRrwonck7kTKICq0AhoTwv6PW7jsh1rsnW0o6GXKlAazixB/4XeQEdwHP+aLBE0obdgCNfm3kdu 1AtNhto+A3d+if9FboTfTdzr/LDcRcgG/XI37W30W/RnHMQ98Dg8hVSQJeRRbhmS4Y294DcbLYD+ fgCe/jlO4b1EI4e5J/jn+TNiUfZYzgYUSaJfoUfQr7EVWhrFy/HN+EP8VzKYzCC/In/hfsk/y78r zYRWX44WozvQ8+hf2In74wn4MjwfX4/X47vxg/gQPoK/JoPIJLKI/MDN5xq5V/iL4DeRX87fIqwT bhe/zk7NHsz+IfuvXO/cOjQB+GEN1P5e9Ci0bB86jD6G31H0FyxgC7bBL4pjeDK+Dn434jvw43gb fha3wFuO4L/gb/Df8T/xGYLgJ5IQiZES+MXJMnIN+SV5mByG3xHyHfk35+NKuBTXh6vl6rklUKv1 3Gb47eH+zAf5w3wO+rm3cJ+wRdgmPC+8JpwQNelmGcnvnH2io7Lj8yzKbsjel92Vbcn9GXmAhkHo hWJUC7WfCb+FQO/7gON2oPewBn0XxJX4QjwaemYGXogb8SroybX4IfwUq/uL+AD00kf4B6izlYRZ nbuTPuQiMg5+l5M5pJFsJveQFvIhOc1JnIWzcx6ukhvOZbg53ApuNXcf18y9w33G/YU7xZ2FX45X +WK+hE/yKX44P4O/mn+U/4r/SpguvC18IariYnGd2Cr+t9RXulAaL02QMtJd0l7pfbkBuPM3aA96 6TxUO8at4YZye9CdpJoPkN+T3wM/z0CzuTEEOJVswxvIDbiFlAqrxIFkIB6LTvBJ6OvXyRZyigzk xuBReCJaSHqZTxPd/HOwqeV/g9r5A9C238OTV4kavpH8IGpoF0YkDe/8LdeTT3Fvo0+4o1jiH0Of 8ir24XbyDDceuOAV/kJhKopxD6MXuUZ8A9pDAMXUM/Im4OOx+DnAhUm4N/6RyyGOjAUu6sf9Fd2C FpE/onaQ4w3ofjybn4fuRNX4evQVehqkokK4SqwUPfhNsoDfSFy4BRH+WWhdGpdiTnCjtTjDPST+ QD5GV6PDvIo+516A2h8mL3Jj+BPCJXg+SMANaB1qzK1Bq4Wp/Lt4HuLwFJTgjwG6Xc/15mOwvQlQ ZTpg2l6Q7v2AA4O4MXDED5wzGvhiMiDEQ/B7AHCCBw5aADJ+KaDY71GLOIm0onmCDQPqgG55O3sJ mpZ7Gj2Ym4euyt2DugEerM9dD0/chr5Ad6Ft+NbsdWgpioDkfI5HC8PIYWFYrhvZSD4mE8l959MX ejuB/ehb+L2IhqELhZfRRv4jNBHV5TblPgDuLgeEfRBdgUai49DK7+ENF3NtqDo7luzMDeOWQnuP ogm5Z3LFWEXzc1eicegAekoS0EwpZQyePGmQUXfhBbUDB6T79+tTU927V88e3btVpSorysuSidJ4 SSxaHCkKh4IBv8/rcbucDt1us2oWVZElUeA5glHV0PiwhmhzsqGZT8Yvvrgb3Y/PhAMzuxxoaI7C oWHnX9McbWCXRc+/0oAr5/7kSsO80ui8EuvRWlTbrSo6NB5tPjQkHm3F0yZMhfIdQ+L10eZ2Vh7D yptZ2QrlWAxuiA71zx8SbcYN0aHNw1bO3zi0YQg8bqdFHRwfPEftVoV2qhYoWqDU7Isv3Yl9F2JW IL6hA3YSJFuhUs3B+JChzYH4EFqDZi4xdObs5vETpg4dEorF6rtVNePBs+JXNKP4Rc32FLsEDWav aRYHN0vsNdEFtDXo9ujOqraNm1p1dEVDSpsdnz1z+tRmbmY9fYcjBe8d0uy79rj/3C483Dl46vqu Z0PcxqH+BVG6u3Hj+mjz1glTu56N0XV9PTwD7iWJYQ0bh8GrN0EnjpoYhbeRW+unNuNb4ZVR2hLa KrN9c+JD6ZGGhdFmJX5RfP7GhQ1AmuDGZnTJ6tiuYNDYlzuGgkOjGydNjcea60Lx+plDwjvdaOMl q3cHjGjg/DPdqnbqDrNjd9rs+YJm7VqY03mOldjltDTqks6exbRG8RHAEM3RWVGoydQ4tKk/Xc3p jzbO6g+XwV89hruaZwNFFjQrgxs26gPocXp/s5DQ49GN/0TAAfH2784/MjN/REzo/0S0SPmkk9Xg fKHcnEo1V1ZSFpEGA02hjhey/T7dqla2knh8qR6FDXQfGg99O7N+QA/o/liMEvj2VgNdATvNTROm mvtRdEVoFzJ6pOqbSQM901Y445lMzzQVznTe3hAHTm5hFq2nWU52/rPrXtfQ+QOasff/4fQc8/yo ifFRE6ZNjQ7d2JDv21GTztszz/fvPJcvNbsGT+VCJF8iIY6dBaac3nkx3ZmqNfMJ+Ccypp7dKsnA lewIjg5r1hsuNtf1aiz2H97UmjtB72Kbc7flq9k8IHX+/sDz9s+rnraRgwqDGhw1adrGjep554DV zBeOyG+A49GkqbHo4GY0GSQzAf9ac2396VIfajagywbTC4D/zEP53fMuDOXL9fBHubNb1TAAuo0b h8WjwzY2bJzZmmu6Ih7V4xv3kdfIaxuXDm0oME5rbv/toeZhm+qhr+bjASAUBF1ExXjwpKldCcS4 vr4bc28wM1AFBBavhC5qIfi4KLWSBw0XEvjjHFIl/jhGAVkUjhPuACh+BczA7sif0k/VdtSO1U/W jumoRXVQ1s/CqlfPmCPmSMAKg9o7G+XazhoCOoOifBt1qa7PTiANwntIRxcYapkdI90pybreiqt3 oy02GbaGQ9piuxxxOhflOO4FxyOb6KsyHafa9VPt8J46eAXO4CRx1PTr269alODn0TE+eu/vx0w7 sGZ12QXxFE5lJxzAP2Lb9590nDlSv/G+l1/JFmej571/jqGVk3KdKKqOkVOhNVC3cBi2LWgLd7kN +KZF18lkKPzYYrezwvEWq5UVvjPsqkom223FNmJ7wZmvYwr+flJPVxw5asqS8Kv2gkbUSccanEqV XFB27ZoD08Yczk7Ax/CfD+y7b+O0d890fPJ99u9Zmbmez2U/x7eAj6KisXtUIMzzYisebyQxV0sI VnEtUgkHO0jsLw0YB/bbErBGtgIRt1oeewDqcjJz8rjeXqsDYehab9c72rHDme7Vs7pPtcctSmV9 +/bbe2j8pb3TfblDhxpvT44JzLwM3jsIt5KFZDHwQpURWEqWcmQMHgOvjCMSFJbCBQF+6R3+1Fj9 eEb/EvUY096rJ2qEZvaJeQaRCty6Z4/pOu+H1XqoP4cShp/Q6taaldyB+K1wfivP6nkqk4G+ajer tf/QoUPM7c59RdJAIw5N3Ie43Oe73GnSmvvciLrT93OYcFu4HRzhViLshquBfYFHua8R+Rpo9yy8 nt99LTy5Vj/Zrpt0WC90T2Vu0A9SeqRSHlyN8bObs1MDwnen4QkETc59xTuENuCJIjx5J6GyYqjB CC+4I1arT2nNfc3oTwtGgDKA4kAaPYK8mgZrjR5DPYD4h2B1CNpDWxTaKf78SSfhSSJ90pfASazw vRGwWET6SJ0eQbqm0TU91vnIc89sEaMBPQysuYtELf8F6tQLixMWe+6YcQUvricbLBvsb9oERbL4 yVDXaM/IwODQJNd0z/TAJaFF0iLLLNeVnkWBhtBqco240nKtfb34gHSf/qb/E/Kh+KHlU3uws7rL FSMWr+mpYKToClE2FzuWI0AlwwZHo+BaE7Q58sbtJuMDz2caU+35auJMI7jO/ekfhqW+3qU7+1b3 9nqdIABivKQs6dK91b37OvRkvEQSJy96b+vKXSsuWvjeY++vvnvfs9df/+yzN14/MkPewzy+4IUZ u7O5T7LZ7G+2P/ASfiR7/w8nwB9d+P2CdZRXjgIBzwDtVLTDiHKG1VGziL+J3EUelPkXeKwgUSCc ImCN4LdUVnuVtglhigWtuWNMwqHwreFgBA0zgtoYQaGXjQAlV4EmjD5BTTCs9hqh0BM9BRwFH54I Act+XItvRaZwNKagX1LmH+yYGFnnS2NHmvYPyqRicYcoSn1ADqvJmZZB7026/y89VvDXXXh98YvD 35pB21YLvCxB2yL4jTwvKQ7d6ne5xMlWykoOByt8byi6DqWIW4hQFvXRCyIRejYStsGZiEZrHmkl LxsaUX2+aLHuICRaDHjQ4/1DdH0I9WinNa2j64O9KfOSzhdqTidhLzQUu4MU3nPMsDhdZHLETY/R Z++CR1NRsVjIZB9FSNaL/9PbKD/T99G3sZcZfQcKA8WXhVfFl6U35DfD0gitXptkW6TNtl3rvNZ1 m/OA84vgF6ETQe1Vy0suEtLDepEe0cX/yp1AEjC/DFsFqBWMqLosim+Fg+5wOCiHg4AWcjDMWSN6 K3ly9zgHdrRi/x7aAsS6w46Jpi73vQe9TXkdv0zWoCjScX9Dc+ypIzPIEnIT4cl+UoqK8V07TWYH XDmVovDClF5de0fmuMNJKQur9bbuKRtAjYm1qCAB/VEGZ5bV1yc8sWQ/oHjfvn1qgPUZDINcACCD EhMlXjrbj/gSTzz0w7YHr7v5YbzP9eMf3jt18TOvPT49sn37oNpZbTce/GLuol88vNF1+ONvt099 7sCTG2b2Yng7Jfcl7wVeSeH6POksAb9BKeAPI0yZNaXBDq6Iq1a7Zo+oaoUnEuYjFWGhwhq3av4A KMGoTtk/KiUpHenlyR4Ufw71oD/kTNfVgSJpBwq2v66/7kzrB1O96UIpWC5Yvdah1nVWfqjjUsfK EHeJ90p9oXu292rravc660b3baGnrKoQ5Rjn0DgqL2F4L6aEMaABL2MaIrPiPi2a5uH9+8mTKEDm G2VQSwGqaXUunxFdEiVRP+XlaJO0PMnQKYlRUk8SqPHJl+iZ5OZu/lbcf1fgPbwf9wdV0mZYzuFV VSu+Z2cBshgdKWqdTGVM5Oo4TtkTdCWlqElQEFYgIcgrbqx39fNS1GKkk/p1FgtUpGSU6BrFS5JT WorvXXTTjsdvqB7tdlqWt65buGCTuyX27Yur3lo0d/bNm7Nff/jrHL7F/+D65puvf8z9KFl1w6yb 166N7nlj3q7ZMx7uHnnlzrbsP7+k9hkKAg7own7AOCtOGn2dU7X52kPas9qbmjCaG239Jc85gc+R JnKSoFo4CWkg8G9xvJvjeM6KiGblJe5l8jKSwdjbaqiI5+ES9JbKt5K5LwmCahQV16gFNFRN5cQK 3zMtpbbifoZVMkriNVJTrI+02U4oQ1ms7hpEdBIlHKE303ugcHwvvYfssbXiTayvvwMEZGB4kkJM rf6lzrAQDMdTtY407eZ0en33FA9iY7fbocPBrt+HrKD3nWmAnfcNS3WaK+mW5viiolr6iHogB1xj uDXDktaaxqc1I5nWSsKw7ZZmiFsP5mcfXO2o9sQdnAOT+zrWkkd+8frrLdk+eMZT3N6zI5/KPgaC fW/HImA9qv9jwtOAs1NM2dmHMLTPShuEwzY14vGEnRQuLHaej4StNowkP+gMZhWwApMzimtUTign ARt1HATZoKJR4WT4a2frUcHVRRuL7nM94/qN9qH2aUhWXH5bZZBTego9LfsByziQD92lepwu11s2 u9vmctvsVhASw0UrYti2gsFpsxsenK/US3Yev0cFCJDNiNLqOWboS/Sb9Lt0Xgcx8TMx8WPk1/3E XxAT/+ao8wDug+z4XmCq/rtse/4ncSk+X1zOCUyG2pUgJayhGQcsAAzH18vdUwJQETHwY7iHG8Hi Ok9wQFpcMU+MA4lBHrcE1kBy8iueB6+8uWX7pks3lT97J/m446Vxa+9uw/KKO07+rgM36RtvP/j4 Q7vG1XnJf7+QXTk9e+oPb9y96xjzXdAYoJ0HcK8IVeJxeeQrtuNiPANzOFQeMazYagWFFRJKIm6r GsEooVNVxuw4PeLTKQ19DPd8zI7z5Y2uQ+8f0n9boGWmXT+YobTstiiAh0iGZ0hgSHSac1J0ETdb mi0vdM6OrpCvDt8qrwt/KL/vdUhR2sllplSIk+MM9Ggpxk5I9ERZNB6N0RMOWsvxVgL1DOH3ZlBS AvAphTqDVdvfcKI9ieU6IyV4KzrIKbTixEvULtE3V6mUdhGcNrx1vhm+Jb6bfLzPS8/5vPR1vlZS ujtlmmogi+2dZMyjHkM7aGOeZlSAKOLVYwn8FmqgiRIFOCdVU/ES5ND7UbjD7i5E5c7s9leNWDRl 0OQryKAD81o6rjmy9s/Z44/c9vX2zzr6jbtz7LInH7/u2uf4ibaFPcf0vPD7P81qyP7r3Y3tN+JR +Hr87K+3vXb2s8xz9a2PPrBjB9NnMwHzvMIzyIqWGraDVszDPyLzCuAZlcSeBPOKZl3OcYR2yjim qjkStMvLlb+hcUD9GYSrg80SfBMYkQFbnpPBXc001o452T5WP0WtMuohUC2edqRNlQ0MS30ZEXGi FO/rdPabye3ZlG0f1de+j7v5H7fxp7dvujfrzJ5p/XQ7/ha/8TD1micCDwaAB30ojnoSZHJhi4ZC ke4UJ8EeI5O7d3fGIqJQHnFaI4pG2Y16A3uZN5GyU1+TMqK9YEDRAjtp93MFR5QrXMV1MjBX6tHo 5R72RA9jYM85r+F8l4RaXu3pdKdn8hKriFioiGhW5DjzUOwFHM+/nx6DwlmjhB6kr6V3ehikeVhL z7Wv8DJ4F+6Rr0BhoTLUr48XV3hHeEckv9S+6SkoPfEN6AZ8Pb9CbrQs0662Xuu7HW3Em/h18hrL Wm2d9Q7fO47XXc4SkJVd4WiQbqLRHnTTLZqkAhSpiGoo4kcaVGNrd9ylp5e/qmCllcwz9NRyuxEF 6bFjZNftxN6K797b27+8GZxoOL+rdLmn07XxGB7i2dyr07U5CdJ/0oS99nzbMqxxVHHlZYZhXWZZ I2qsr8fJZJ+avFlXsAcQHHG5u8hLV+HBC5de+eWrbd8uWrz+juypjz/Onrr7inWL5t9629x5GwaM 2DxxzbbtN9/0DBeqeGDh1k+Obp17f0XVwQ0Hcgjjtrt+jSfNX3vLjFnr157Njdk87ummm5/bRnFx HwjROj7JYjr9QS8ISJQUItbyXC0WefDGQU8hQr2gx+R8xKCRygLYd6xdrGkucMo5WPaBY87VHzp0 9hlw0DFaiv7CD+R/Q8d4Da2J3MWDJsVge5CXyTQ4zZNpuwQD9Ml4JODxhgc9Lz4f5bhaEQXlqICF q6VLp8ELv8yADNaOaUeBHsF2+PMHdfPl1OgCewv3of/4gWf7cPhsjnubrMnO3I3rcO3u7FwT+6cB RmjCeyiCStBao8em4O0hcn3w+hC5IjgnRBZpM21kGrgRpK9tiI2EArLEI73M4UDWCjeOAIzsMOKx klhtsVpcW1ISrY3FIujyyFXq5b6FpfrlUXAWFsZZTU9laEgHtF8tDal0sJDKqVrG48cdzETMwB/K ZDAQvl/ffheSrnYhT9nARiTakfiPOOLtVfpy/yevWf6Qf1/gX29/hNG0W6b2DZLWQ3hBqXPhmAED U09dMWDBls0Peg998u3TDY+vGDuy4crs/TQ0gkiuAyGhHmxBCdnwvL3YZteZ0fX3lnzhR6ZwCEWI eibcTFAFtu6h99TnyfOVBn0Dt1l/U3hdbNNP6BZZqMdTyHh9vqVZ/4f2D+s/bAqv8VbexllUReB5 sNVlUZI0KMuiJmEEnvGPhp15ylFJc8MpwnH0mIce46K85oa7lIggyBGRE1vJUkNBsvaNQTAh+7EF GNdiOLUomiNxl4znD/NHeW4zj/lWjA3LeK1NOqpxmzWs0X3dLh2WyE1Sk0SkX9g//Mjk1AAs8M8P DBMM6O3tyF9XG2yvO84I1E7jPSmwQ9Z397MtY2iwNNfrBw/aDh5cL5hboNuoZsvEUc2RCdOmtvB2 Tpb2gyOJcj9Saa7Hyxozpv8ex9U4zsU4V4xLlokSR6r/QKZ+9nzHrx77GP/3g8NKwtXC/tPD8IHs EDIN37fvmjtup/zJofuAP78BWjmYdeLah3igynAa2eH5YfEp8bnx5cpaRVwQvFpYqiy33CLcYhHL vArnL6uMeIsUxeWMVFZWVKBwUQR6rhhceiT7k6JGlYEIVrpRTbWB6KSoL4q070WZPl1k1BbdlBPE SYmkFqZ3aCq9TqOc4aFXacGqokiUBUKi+SjIKaZeWCEfATndwshsFkQzJqKyOEgmNXC6vzPGkWGh YLozpv1kPuyR949hAUEBualN93CkqV9lulU0BlLtiHXxm2wkjmO9Tec4GQcTvrcpSlC+jyS3vb18 7rxb77q06debsr/AF6zpP3LUsJsfzX6KF1+eHDxtwKR7N2W3C/vr9825/OnqsgNN83Y29OIucXjn jhmxpOLMVknrv2jYJat7Udtibu4rYSXgRhF6b88ssrCIYFPtsvZ9bcygpSjqbZ0FSLeiqAmtLdqM HhKe556y7uNarG9Yj6DjRf8octicRY6iIq5SLHdUhqPFw61T3Jd6pgTmC4uKrnPe7nyIe9D2UHgb fpJsc3xgcyE3CupuPcjTUOau8jTzybuVp3U7wnzIFdG4UIRX9KR9JEpGMcbBYl8yKmNZo7WRA5FZ 05n1ksqMobYLrPPWmwlAQAEacwPDbRn2iXy8pBQ6zlkK6OOTkhSLiMftpBqHb3ntguxvvmjPfvSr HXjwa3/CVQNfrX7tF8/+dfriL9c98RdCev1w5tf4qne/wJN3Hnu729Z7Hs/+cPfL2W82HjAx91HA n2nA03bovS+MHtFiPFg2+dOhR+xIhkoruJgFHhTGVorKYqd+doQxH4OlYHGR/h8z378KzPdjgfki P2W+fDlzjul69Ry82ujLhSRZlAWZl3kx4A/6iWhRQRJUTvR43V6XlxNDnC+GnTZY+eVwDHtVRwxB P6ZSlfC3Bmcoj/q8Pi+YvwQ4NBHrnY/fgG0cexT/+/lpN9avWD722rsP3ZrdidN3P9Vr6Jj7rxy7 PfuOsN9TNPqK7OGDz2Szz87svb1vr6HfPP3lvyoj0OrHARtofpUF3Wt4RCEiy5KEOJ52pKpELEiW KH8U6c4aaRI3MqpGrUQNWnnl/4PAagMvM1ko32ljmMhmxpw8nvqppPbqCa32xPLL43zp2Ue51NkP uLXC/u3Zuhey1u1UjsDQ4G+FNijoDiPF2nCXhDubAU14OEqiFkKClv+g3obFjKXnxTD7s+qrA6d3 qX6X+h83TXjqwvy07tu4z85+QZo7xtN6D9jeMZf5FotB/veB/CewywiG3CEPaSjDl8su7ORKS1HM 6SMJFCFMQKO0FhiLvoiNA6tSwThZligFawZaVtbAAh/HWVuYDs5HQD5hNGA6OETvJ8uaynBZUTKq YpWFktVActZlneI8Rs+cyrcIqk9dsU5zvZbtm7GoNHVPgKWH8PFQOBgOhDlRS+oJT7I4KSf4ZDzh txbFkNfuisHFbldUgr0SIRHDYQvwttsBq4gSi6FSDlaIOXkpOkxSmyr8UW4Hw6tPwnEegnh9UncC EELH2dxOHkCkn4MbTRbflT2y9Y/ZLS278fhPt2B8T3JH7Iq9S2597ZpY//WY3H3jiQtJ3Qu449iy 5fvw5X/8EC9vmdf6y55Lm8ZMWDtuw5aD2R+bZvbDDqDHk4ApJUwW/kjjPm1G0OWp4bmIom5Vj6hE FQixyCDDUUkSaUyKaT3ob+pSQ4k57yJ1BPxM+2Gm/TJN4PkTSzQf6W8zVHjof8CAcp4Bu2CONy8/ USuOgqPeYF1q5QfW+8GH7gzxmxhk0jFVywJcIE/gJzAgwqDogClhicP6ydfI6dde6xCF/R1Pk2mn h5HdHWMYX74KqzXQDxx6Zw+VH0IHGXb3v4ANNuyurjG33Xqa2/IKcxtPmNuiiLn1B83BiUqrXhMV Ngs7BOBWMNruQltRM+J7IAONR0fRCSQ4o3BwM+IEM5pH+8Gf75/vCv3zfaF/Thm6afGx/nmc/7C+ CwAPnj51VxOYdZn6xmW1HZlCp9AwHxXHaserr1ETCdoINpFwCaU1zhoRrqRfWlYGlKl9xL7qcPVS bh33ESetVD/mPgaApvLD1Ea5sInfKDzHfysLKo/78B/yRKHkVpyxGi5KV6BSd2tpJz26G/bl/Jan 2yK2bdvt9NLjnxsXBOCdicQFshIIXABMraiKrAocz0cF1S0IsAeMJoJVK6oqEgiPiWSRkaxyxAK+ TSsZYNh7Cnir0Cy0CccEXhgp02OWnhKOgpXaLHFSK1lnaJbo/xao/34OqLdRMzfft+0d4JlR74zK ai1lrNpaugA+UEOXjjbA1s/ip5Ks18q1YNb6wawNgVlLbc4/9q83HX66c2K35qD9dcLwQUHUbY4a WbfpNQotqTrwDDLfW8+sCvZHY60OpQT6rSqQ5ulSEkoD03y+1wtFb1qk3WpxpuUSd5o33GnazXsS UPSkU+f+6umDceOyTApRw5pyBY5h+Cc57nuN/BFLHQ+Sm3Oo49QJEIwK8lHHi2cfIF9+m+WZbFBb uhL4RkCLDQ0TQAcByVHqNJBnDLtEuP9YMZ76mTEh/syY+DJjakSTeWMeqOC7wMD/2M7q8gBCoh3q opPjhXixDPLB8EO2WR0M+0FwoCDQ4blyWtKc9LRg1zgFYSIrFhuSFaJaRFpji05raYFa7qVXWXRE g/D5tvxYaMvZlvMGmmlYp66tTT9ypI06zamUSTFUGHgulpisimzNsTXP1gJby5Tj4rREmNIFdUJ1 le2c16iytVRwKmXaZcVskEXAWlR11tjZStA4hG1gsshgu9CG06exAnvIy2QKckJfTTGsee0uFgjA HotokCh1sgfwOwPNWrMxmXP8lzJZMmTchIhddpOQzK/U1mm/g67URmgj7FwFn7BW2aZyl/Errats 662yhQhy2trXNo6M4oZIhjzGepFNfYA8yN0n3Sdv456RRCex22w9BQIST2TNau0pyFCUtUvsl2AD 3FSZZvsDJtpsOqVTg7PJSZz7yTZkxb12CVG5FfcyVE1Ro4Z2kwVb9kMjbdgCZ0grOLeKHVjRvlTH eiuZ8lJUaBCaBIBZsm23gyqOAM3PyNT6gdOY/wrlYOfO8Qx4s9ANepdfEHxcKuzrb2BOLWx69UTn nNdXkJY7Azz4ISK5D5nvOqpZg3PlDAGsuR932lR6ND+w8v7eWNpWFWODK3v7pW29+7Hinm5wND+A kqoH7xfkFBC9HgQAe319++EYqC8cx44HcCm+rKc30AfPwMLL2Sk7slOF/Wf+fvfF43/FnT09jH/7 TB/+2Jkok5WHAe+LqY2Ib9jptBT0sOzXvCyO+bURoyWZgI6SZABdmUgcJys8IYok81xUFIWCNhI6 Vb5gyhIoaSPIGDoTteCoZbylwbLU0mQRLDLYm0zpW+Fl/5nhyf9c73canl1UXSqTYpq+8eR5mt5J w4Hp9Hqe0agAt1zu2EuAsnIUVohBKjW6gAotsjEsDc1v2zssLRu9zWLvtAQYS93DvQEo9jaL9Gjc zH+xxNOSzQ2Li+6f3OuCYpFZLIKihxZ/3NkJuriL8AARqzG1P7Dj4Tc4sv+Ns1kg2Rr+JiBX05km 07ebBXbxZ8L7yIZC6C1jfNCO3brbHfKFQjyv826LzxLin/Xttb1u43w+f4hEiwzHONc4nxGcKkxV LtUnO2a4pvlm+KcELw3d7nuQ6IEIxzkjFsWTjIJjQJ1sSgapYFVINLJMO1+iY2i0/yWa1pAfITkN rEHhJ9hUhIvsSUpFsQt8BMIFj9h0iTMF/B5zXhYKuMUuHcV689R9Y1ZtPx1V90aOGgJuMZqFN+C+ b+Nhz7dk9756OLt/2+9w0Uef4tDqb+7+ffYj8hZejB95LfvUn45mt+75HZ72X9l/ZQ/jGhzajS2/ yH5h+sN8B/C3FfnRLqNqjmORm4zSR7kv0y9z8xYtAiiDfH7TH3ImZRaDkfU8/ub9AzkYDWL4F/Rb /7du0s+9vEBXZZaPyzRmzMhMp6NkWqVg7DPnNkKgb2IxB5Q7/VpScc+YK++p/z77ZnYDvu7Ao5nR vdZmbxP225xz9i5+OdvR8QKHN900/RaP1eSdqbk7he+BdzyoHM837p2R3JIkAX8/D7GE+WLqsbiL 3XGxUujmSyUHCrW+AcnRwmjfiGRGmByfmlwiXMddK2ziNgn3ooe4J9Hz3AfoA+8X6AvfF/5gWEih SmGgwGeEe/z3JT9I8glvZbLGm06O8I8IDy0eGh+VnCJPdUz2TAtPK5pSfGn00pIFwlzPouR1yTvD dyY/9f8pGbD4sQcwblcojeiQcv9Qmve7/ZXCAIEnnLeck8qTfq+AxBjnCgqE7iChNBKxc0QujUhK MOnyU1q4CrzrYikSGiucYLzrKvAuLRgJShfXSBKMVjZVkspYEhDKwvwTC+NfS6Dip/w75mRn3Ky9 jgV28n6fL40c1fqb+puZfKQHLaPI3LgsAa5Zskzs4qtRLoejffPs7aC83i9Zxv9z/bL0o4888ds3 sgd2NOOhb1KWv6rjy22LnwdO/zj7Fxz60/zpl815JJNan77usjY8/ZOP8ez9v84+9cme7NE7emQe xuldWP1F9qMsXJz9fdnAAND8McD27cD7flSCzxoxp8WGnX3D04rnyouLeYWlS8lsLbF1KYAc6zKW vEQLWqFgKRScrbm/7HYGa2B7YndJWY2D7heV1ej5rT2/hfN/3F2UNM/D9Xp+S88bI6CQsI0Mj4xO tEwPLw4vU1bZVttvVTfY77c+a2+1f237yq6DnRN12N0Oh91h1xRniMSCXlV00nwnwa8oXl8wEPFR FcLS83w+FCthUuwHPrDJkaTtYbGQGCgWBJQ5oSXMHRVZ8DUTLV1a2lTKlZb4/1PJFv+veihO3YKf BEDysBc47qeBL2oq5CU8Bedq0z1YXpKZliR0ZkB2+UN5781QZcOetusDHM4BVF3gRmYr2EDrBANp B+glJyw2I5zWwcjXS4ph6VQ09V3CuD6vzxXnuhMAkTgDFDbGFXuMbDz4zrVvvTemfPLo3MnXJl91 abfYqD/jx269b+z9T2R7CvvH/W71wx8WJUrHXp1txL3WbupvkTqu5qr7rR4+n+X5Tc99xf9NeA/1 JB6jbBY3i1/OreD5RFkfLh0ezI2QRhcNLR5SOqxsIlcvTS+6tPw2ly1OQzK0v0sLhUShkCwUygqF OCOFebFZSBQKyUKhjHrBw2ip3JosJaVcWaKvvSY+JDG0x7TolPjkxJWWhdZFtrnuOf7Vlmut19pv 0K8uXZ5Yx2203GbdaL9Dv7X0lsQ91vvs93kieRu9WyzpDCWDSrICJxGqCDr53r2SaA4Il7Xb6tBt IRJKeK3dImUJnBC8AgUWczwn0k2JRLwc03QpwIiMGSaimwwbQuvRbv5CRrdEqc1qEWLhokhIlkSe IyJOlJbAMVGIhLoFDcp2d4H2afeibizoxawrHUfxeNyAl+LNWMStuNlwdaOvpK+GGo9UkqgCV1DF bbORyRW0alZ6X0WwN7QJJ53UbKOnnAUmd3YOGzknUVkI9MoHwTJjjlPY09vZCMK50LbekUkdp6uT tEXAxnQch44e1NMBwsZzXAxY6OoXIdW983HZ0jI2BMuSsvLxb4/b5+V9jEkpXianv2Sd8bsbljw3 cfz0gdkrJyyYd+Pff/nEv9cJ++3bn21+LN0ffzy16dp1Zx55I/uPB/FH+lV3XHrR8iFD58V9M1P9 npiz5NezF7yzxnb7nWsuG1ddvah84J6VVx9evuIbM/e5J9gE+9kY3W2GVSAR6HLEpj8prWT57qg5 0vWSGMWkBx1+xngPzkepvjYsDCDkPDr8veC0/qUAE2cLsJA1nSf6RHnvg139V+hQsEuPZ77UWf53 XSEpvw+NiBJXtojfmA0J1u3bT//DrO9jYPfR+JsbfWyoSftUfqr8psx7KSt4wX6u4QfKw/iR8kr7 08LXdklDxNFKXm4RFXeSFGxz0mmbEz0f/DxmhJlzmYl6cdQ73ksavEu9TV7Oa2WB0IIroEbzSWcm JKoFblE7IVHl8w6lCYlqJySqGQ81zc9BYipDg6mZRtYVph3I7JwUyuBqR97+6wNmsDn67uAbXpud PfP+77Onl742fPsNH+4V9p/d+Vn27BN3Yus33Lizu17dc8VrLMscKaDrhtEcPHxhPsvIKWAkM7tO RYIiC5gIPT47pH92yFFdDb1ex9JJQkZpDwFXonIuofbQemoN2m3ybcpmrU07oVmi2niN8MQik3xC hoI1cKPhkXV1bMwS7lYVJSoLblkWEDAJEdyECAq86puoCn7pHBnPITIL35Wnx8u4Sd4swz7GhpUY 5ekZBN9FthBC6BFHVBgvkJ7gi24W2oQTggD+6IbdloZtpj/aSHOW6eLXzbz5YKDdb+bO54dS6Uiq 6XO6wa/chexAif/epTgx3YBbDqaRmQhB3c9yuKwvcz8Rm8jCzHGaVBTD1aY3WY3JoI7fvYtv6F5c 0g1ver3jNfBIPmpaumoVX3F6GO3zAELSSmpf4E+NZAVKOiqcSX8a9XWknX39I9BwxwjncP9UdKlj qvNSv/6A/IA935FGtY6DgZSnRqjRhghDtFGeScIk7TLPbGG2tsizQlihXeexCx4at3DKIGyE0bGu jlHNxxCUdn6E4wWBiBJ0vgqcqFhtdrvmdjmddN6/H8zJ2t0C8kfpVnM66NaY5gHXEwmEgP/pxhj5 BVmOePxuj8fv1BQl4nFC0enQ7Pao7nDrusOpaLLfI9gdOsgVVEng/LrdriiyTKBOfqfT4UBy0OcL 6oMUPAFFkQZrDywGEvCEvVE6VBgItOLbd5rGQSYYGNMR9Hd0BAMd/rFD5wz5stMuKAQTqE1AB8QL C7itY7qGFs7fgCStt+kHD8Kq9mCh1HUFxLYDsR2UJ5yqH+TX5IAEHKw8xwH5cIUNjuzWDMHobzLF sgwwhMtkCJcTNq5qHMd0mB3jR7PXvXG0NNhfxb5v3x0XD3f78jfZq17Ovl0m+dzZN0FW6+6/92+l 3Ocdwex3/7i9hXsRnNnMpuic4WeeYD7JyNzXfJi/EJWjfqSbUaVYlcqANVhZYa2sTFv7evqFBlSO qMxYM5ULrQsqG3putK6reMj7q+CzVk95YUC4jM35oKWnA8+V7w28XH4wcLj8Xc9n5fIQL45Qreeg oOR0nkuz6EOxbzItFfuK/amqypo0n64awV9cNUWuT82VF6RWauu1N7V/W/+dcvSrsWFe71Fa4+sd c/tnVCypIBXhHrY62122LbacTdhi22H7wcbZtPwMpG8Lc5JOGh6a9W9jKVg2kSZo2WxhztdKntvr v9cdDkuIXhRk6mJomdo7zFkqZuozkcg0SSJWSrE7bx59Z2J3KU/xtpSOadGsslJqldO2Q+FPVDNB ib2otKCHSlvJZYatzKA52NFkz+SOpJCmVj7V+2A2fbiXFXqlWSgmEq/pmW5Lk61pnPbRug2iT/Ql /CU9Sl8VD4ukWKwTiWhjJjVLZRP9zJZmKW4ic3lFG7Or2Sia2Kt/lykWYDSkdIAvluHYqRBqO1Jf fEH1wPFUIb27cH2jaTKlOzOOmCVBQ9OoMUGNBGZC9GO/PjVlZkLPhYTZFF6Px+31xZMczezxsLwu uIirnb1v4Y4Dw5df3GfRJ/Nw9dANN60uavZfdeS2Dc+N1xVfyYGw74qDS6b3Xrxg/uPJolsmD3v+ 1rFrxrpt1mBpQr2q2wX1jf7G20cZM0d2X3XizK0X9MeflYf18jE9Lm64bNwF1zCeXgc8TeNpdK5S k/ErLGj2UqGPMFQQ6oqbi0lxcUm4OnxReGnx5mJxgKvWWxsc7R0dzMgZ61R7xnt5cKF8pXW+/Srv VcG24o+1T3yfBP7i+s73XeCvRceKc8WBqNDD3sPdU6izG8Jo+3hhrvBJ0T/507qme2y8SFAoDIKp esI2i7/0iAXrFsPSYGmy8OaIv4VxqcWfD2afKvh2poNsKUx/stD0V+YEUy7oQSlqWYEd1Yg3I3HM sKnmEoS0YbA+t+JmfALzxbgOj8McpqYPZVtM0xGLKINhxiyYGR7YSZkFM2bBNMRMeYxd6qWvxn42 oMtSY3AgMrzfeeYD5YtldBQWjoDhee5g3iWvY/krLDsNLkSNsTjYEmBlRohHR/GSMg6MzHNZfd2e aVm284odjUb2768cWERqJt+98oWnrl75grC/4593jbvrreXZH7IfPoLve3Xy7YfePvL6IWaLjc99 zbUDZgXxtLydUWO7yY7tFkyH7ZYiDvHOsEXyh3kLtnkkmbZfYu2XWA6opNP2S4zLD73/umlHH8z0 pgs1R4YrGi4OD3YN9k10TfQ1uBp8vyK/4h6yPqk/GdRka0BdSBZwC4WrtaXWJuvT2h5lr7pH07za Ou2vhLOVzLAvsd9k5+wYYMZY3ZONJTZAtTajregYOgFmkt1uQefqGIaql9pkhlElIWhfqSVVDHoR 01QvSiKD0ediRpUgo8qIsKf0sISLpTqJSDYWFVTpRRKDWKlXqOZg3tqlY2LmyPmy/NxWlrjfv759 2clU+7LCKLoj3UPPHId/zGsAytVjn5nIXMNmpXV6CJR2XO3Ooh9e/CT7r2Xf3Lb9T8U7AjdN2/Dc k2sX3olv9b10GBdh9QVM1ux4LLToyt+89+FrN1OZHAY0O2rmeeHJxpMq4a0Ja411iFXo4+4TvpRM Ui9xTwzPI7OFOcosd0O4rfh94QPXZ4EvXF+4f/D9LfAFkz1vcXEqSAV2VJBKr9SdlFq7eweQPtZR ZKh1mHtE+FJ1inWe9QvxK+9pfNKmYw9ns+h2kEmL5EAglJzFX41RwmFP6PoRB9YdhqPB0eQA4aQ8 YYqow0llx8EUFxVWh0g5yMFE1sGMeNrjDhvtcUdhDMdBTe6LKHUcK5ylr0qHpaNSTuIpicZJnBRh LMewWoqYrMjIxlSTxDSQFIjUjO+afdI4pr2jq9ixKaq1x5nJTpdzkkbHIWJ9KB4DIJsEo0OHXZNp +885eNMHVy98/5aG+3rs7oi+cPXKp7Zdt+qxdY9uOvPEFsxtnDCI2E4PI8533vr165+8c5DSbBTg aATkzAM0m2j4ilHYQyZzGSGjTLbM4RYJS5Q5FtljzvhlHXDcuISWisIss9/5sXDafSrI93IOCPQK D3KOCQ4KT3BOD1wSnulcHJwZXiWu8pwip/w68mK71ecb76XeD+cN2zfrW3Wi63worEpoP3mOcmwB z9pAGqDfdZCOe10gPT7DCpqXuUPWwmQcK7UBaJda6fVKWWVNsxVbg8V0iDuRrKFbYxBVtcW42Fut l0pGaWVNgVLRLpQKM0qZAhZmNGJ5DpRSXVExkxrTcXysDt72qcZOt4oO8ecnf9R2NNbmM4bzSX1s lLcgYmaw3S3FmMeFY2xGgchdvr/q+33fZH/A7j99gG347Nfqrltnber4hEzQ+k+57fpn8RTfEy24 GOBew+XZz7P/1qM79s/H964bPP9phpMuIGKT8B7yYasRcSvYHugR6BkwAksDv9Ietj5rlYPWcmtz oC3AB2iPlAeLa4pkK6fZwyr2kJTbxXMiUre4sTvnMnhfgkccuQezQaPdvfrXsMGjVLi4ZjPCAYMK SsCwgqAgN/PPy5l/XkJFB1XlPfO/5wN47nwA71umethALptECv4sm6+BnvAHDuD9KIZOYRX5U6lT XeJxGTqmdBKMdPDB2jPUea9lcwzTDjP5x607REUSZbCTdMUZQg7RHsIpnKpcswanQFKWVTvifapp FjIICgAbxTUPnQW1a8sWV/CWlaOnh/r3vmTI4cPcQ5saF9UMu9T5iDqs4YpNZ+eCTFyUncB9CzIR QZV4idFgsQjuKkvCPdoy1C0qRYGiKkvSXRVPW/q6R1qGuadIUy3zLafVf3ps3eNVZRfGLywbXba5 amuV1DfWt6KuaphlWGxoxaTYpIoF0qzYrIqGqqaqT8q+jn0f/6HM4fOKnlays6U87JKYLtGjqCfT JE2oDR1BYLySG4zeQjhsV4eWhDXV66lOVKsJv/+ID+s+w9fga/LxVdDlZHIVAzYfAzZfJ7D5GLDR CTDs6LcmsNGr6ISYPLD5qGEwks2RWWHHCVRSXPqq/bD9qD1n54vtdfZxoOqYzNiDlLb2EjYlg8U1 zOlcdoZu9kCqakWMAlxqbBeAO9mu/wTjOo6fojOnjucnTx03wxONoJZ8NMWQmZE0nk9MpPP1qXaw eFWy69yBuTssvQevuGGD34ZXNn964qo/3HHg2qfnfLr1v7598Okbrt+2/dpV26YGJyR6z57Wr/l2 XPvZAxhveqDp7MIfD696nqv8Q9ur7/zm9d9QGVqPEEdzEN145j7kBcb3+GrY/ExmZCf4PtxQbr+V Z4cG+AI1PtmhOdycgJE9LEhui6olFKO6b01OwW0K9jIt4zVY0mc5W7spCRTqXjhY+iez75QgvU6h sVRGEsVNSaJQFcOmSNGEUbZ/ai9LRRjLAlG+mr41zd4TXrLUu9Xb7M15eS9xJ8xBXh3qcIJ+NyAK nHMM8WxcLB9oP234mJTyheSuLkO9p02bEBEmloSZnWM9w8d3GT9jc7fZeG/qZNe4uTnZvdY0Cak7 zaTTJtqkhE3UQtgqg1wiOgS7BoFQmwlg5iRRR9zByCh6HOtbbmxb+eKolqsXjb+jFszCv9+TefLh jhnksfXXTbzzho6XQSY3AKFqWU6YhA4Zlyt9aQvGKZuVrUqz0qYcVU4oElKKlaVKk7Ilf+iYklPU YgWsLIknnCJyN2IkCiKvilJCQPwWfivfzLfxx3ixjT/BE8RH+SOwx/OmvUwm8539xrN+41X6Vp4h G19ANr4Qg+SpEKm0D/mx8k97b1ktm+wJPYULAQfK8ssaU2xyCfTKhpaWFv5vhw+f8fDJM5/QOQ6P ZyfgAazNTvSBMZQXEsJAvlpYJwg+WRAknie84ELYaiGcW+MdgkWiLbSIUthh3wyI7vOBVFoTqrrZ gostdZZxFo6m1hj9aIvyqTbMWbAwz9ISYd6JRhtlkZlfwmTbEnC5t8eGd5VqJsU0S3OsTkMrjahu DBuqc+aH6syASnX1el02849tsm5PyroawopNCiGTI+jnMqo92JxBTKORdBbkupbs/JK+xf36tlQP un8E/80f/vDv6x60jbiHn35m68Exs6m8Ai9wP9LcOTLTCImmdSVOEacpnN36D+GUyCmFqQHmYJpa KCiFAsu4YINxk7lrVOIUoy6WLXdit7OsRqGOGmydAjsQYweMtXBE5HmBF/spw4EUYjd1qnoNd7X6 CfdXUXpaxHExKSXktNhfqbOOs9bz9eJUqV65gV8tPKi8Lr7LfygeF7+R/iX+W/Y4VVXgOJ7QrDtF hh1FlhNmrh3H8wkz/04FhuVpEJR9cxMkFql8K7YbisCzGEuJTPdiUeYf6GaKwGYwgSwJRBLgLyJc h8aB5AB7Gr2Y7DOKIzN9kXEycjIEYA4FYs4JCmjWP8eGz+1Ka0ZqNirReIqNSqTOjbGBgepL09go X0i/o3l4EpBdruXYOh+JtI5ScLGyliOK30qTQMD7MGc4G6pSVZRW5KKiWpo/t6uIptG9vyvKNjtj +XnMLAenEbEcvH1IzLXtirFkkV1euvl8l86S72DD9jS22Wkp5PDgfPKe8zMey24vvM3trmUrOmS5 y09v/m5nKJ0fRKk3YyB0OMVMz6vGOI4lkFD83DfZhfjVz7OP3STsP3sAN2dXdswmxddmL6N8eQus +jF5/etegQEUS0Tt199MSK3pY2579jK3JWbCqpEAdWMXioUtwlGBHwerEwJXLCwVmoScwAOaq4Qz AZ4+iQG9ByybLQi3gaNJuqL9j+fQvqgL2pu0Nu0xOW+MFYZNcrnCQEoeu9BY/nzsouBFA0hmEitm e/SP9swtLSyd1dShYhJspjh+g6ZWnSxkyp0sfN/lj8YYi7UmwR/njyt/9n0RFT4QTkWJT47GFX8o qnBcPBIWPdSkkLAYDwZ09UgCb05sTZAE4JgtsdmBHTzz2VgCgoMF65jP5qaNdLAvftCGOgjz3BiM OViYzlHID3EUcu0crThjaP7E5hAOsceFOh8XYo8L0XxFB31ciGnJEHO9Q1SWmHIOafTBoUL8L0Sf 50WkOp7ARxCmUQBSjKj8cUz+in4mfwxxkTevgc8WbOSThpupYpMUNlMkSxOteNXunyKwGaPpON4l bNMl4Ac7HSzs3bjMzJStM4XY4euaQ2/T3K6kW3OEsNPqKSjqvPNCvxrAhg59bA4nU9fMju6quB/r /fTClfcX3/jWo8/tjk+/cOkvW6bOHr1mAJ+8d+yMK6bu37G3o4w8cuWMAfc+2XE/2bVq1fiH7u74 uGBzfQn84sU3GC6BE11km96q/5X7ynWCO+USeQq5tcAwq3X8gH7Ef8yf8/NR2W1ze51gc2HRa1Wt Ns1W6md2lp/ZXBZmbVmYtWXptLYsTAgsJewK2sPM2rIwawv2/20S1KLmI3KnDAaHFmbQWTD8s4z1 U6ELUsvLf8JPlvq3+pv9bX7ez5Fqj5fJ5qkWhyOfXvs/GlzqTwwuRxeDi89LYpvh/KkBN9bHvieU OhfGrT3JjLDzjtJBYzbEWUt1cKcV5hUdiiqrksqJetIh2kLYrjrzRKZTHBopCjMq52O5XUi8/vGr P2t4bLyutlQuunj5M3zy/h1Dl47pfUPHcrLuqsWD7nmnIz8Pakjua74M6GhFAbxor8efT/z5mokZ nb1tLKelADvhlNSANly8WJ4i1svzxAWyXKMPcA7w9vEP1Uc5R3mH+qcL05VL9Iwz473Ev1hYrMzW FzsXe2f7r8EeRRSsl3GThEnqZdqV3BxhjnqlpvrCvOQA0HCXhpj3E2KMIHV+yEhiAZ18MLAQgGWF fHadOaU7n4HHCm2GqzRR01PCSNKlqMRJvY4CStDjI2g4Acq2UqTZqOPLZhwiFm9EYUZhFkbIyy1D IMS+P4AMeCQFBIJ6BWlYIf+RNJN2emMqcyrTJSGlM3OPxnyo4lImChOVK4QrFJ5qJ3qJi318AOU/ RdDVLRry5G2//RR7r/vb7Uez7ft2rV+3a/et63cRFy67c2X2zx2H/nYzjmDrO2+/84ffvv0Wo+H6 7AI+BjR0ogi+wrhT07vpF+ijdL4u2hwlxdEKLV7U29O76KKipdHNUXmAb0BopG9kqF6+TJvumx5a KC/SFuiLfYtCbdH33J/5Pwu+FznuPh45Fs1FvXE+pac8ffgB+jB+pD5N/8Lyt6KsbnHYOG+YhtBF b9hmQbZA6REV66qhNqhNKh9lRIwa+eHvLw0LGxH3F4bDC0ZdZ4a1GU5XKbfF2dD4CuyqJtXOBEL/ c+S8EDDXuwTM9fMC5qd+GjBnQ1oAkyxgXjy8nx+fFzEvBMx/Gi43U9jSXaPlrgKwej1u+hWwZJmD 60K/9U8OuGf+hiMLrz563bS7ujueXrnq+WdWLN+ZXSC8snHChE25B57Inrl99ICOM9yThw6+/cHb b31EaXhxdgF3DGioozDua9xpISlS6R9IRpHVmljnqQuMCmyObI0INa6aUF1kiGtIaKJrYmiWa1ao IdIUeV/8wPml+I32rV+vICVaypMmfbQRZJg2jSwgH2uf+v/q/SbwZegssWPe6g6GLZJNdId5IJzP Vo1olNWOdbthb7A32fkIC0ZEGPXsLBhh7wxG2Fkwws6CEXamTFk4wUv72m5mEorm5XUMP1Y4fh5l LWWyzOIQEotDSF7T+DWjdkWR8yMQ/0OEteNk7c8JgxqxIx8N75sPOZwXW62qvH/yK9kflrx3428b H++IvbBq+dM7Vl79RHYBkQeOxd2xtDV7y9N3nh7MbT906DdvvP/hG2ZOya1AnNeBLg70pjGwhwvr PI7zNfxgfiI/l1/Bi4pDVmTF6nIoVsTJ2MKEAqlK+WYZyyVRF3aREsf/3b/vtPh+NBxd1I3IwOg8 u8J08cUupv5Y5/CDP3Pxj+uZk8voTELaOenCZ4mQ/uZ6G0u2zyyjM0FNBjbjahKoi1sfv3BB3WWX X3jRRQMvd0f45GONFw94pmx4XcOyjvfNfqjLfc3thH7oyfmM6/gSd8kAZaQypHRKyZyS65U7lbWl T7uer3qNsyq+oN/Xc1TVhz4hRCYTovfGqn+6PF2Zrk63TNemWxfKC5WF6kLLQm2htSXZUmanaU6l FX1Lp6n1ltnJ2eUr4itKm0p/oT6s3VN+f9W9PZ9Un9WeKHuyfHfyt0lvecEiLSkU4oVCaaFQbnqJ +WtoIV4olBYKRTQP3RlJT5PLEprKB6NJD2/pXhSkIbySQBUbZwjUBcYFZgR2BA4HRHugOLAkcDTA FwfuCpDAK0AdD3AGi3obbnq5Tqdb6PgIOHxYx2zW5W63t8aMhtscNRh3n150ZREpCnsk3hyQZgGK LwtBiC8NFyUxH+5uKQ7iYGnAcPlretPbe7C4rd9cU4kJsO81BqL0zkCU3hVgDmSARb4DreSyXVJp Jdy6J5w+Uokr6VvoHZWFTM/KgqxC4Vv2fZTKIHtVrKyypqF3W29S17upN+lNI/ilyG/avYzpomYv A7zTAq1AlH3FhVYiWmpnIGxn1bNH8yhx2ogy7GAzcvLhxpKjBfc20CsfpgdBLyQOw6LDZtnY/EB4 KtXYZT5+yhwTY5/5a2QD4dSnoQl2dNM5z9RnWlFGWbdIXHBXJR26U3fpnFhijYaQUi6FsNANVhE3 7MZs8RAqiVs1uUIN4fIyRRVTfAgV60XU3jJnl7IVm4tQmVqzZg3qAkk0DpTp/DhUWbKsO+lT07ff zxL34Edz1FkktG6X/bbrrl/VJ/GL1x8cN6h/5d0Tb3hlmqNZW77g+oVeb4/Q2lfvn7Lg9RsOf4wv CC9aNmfIBXF/oveINWOHry4vTl183Tz/JdMv6RcPF7nU0upB10+ftuXSF6iclub+TiqFB5GPzkFV 6bTKJI1/tBmDoNAUwAhrVhVzyKsrKbsK6puz2PUSVIKtzoSGc5I8VBnaIC2VmqTNEo/AftoqNUtt 0hFJZNMd8vMeTjIukmhiHxu4Nf2yfCE/E+I04w5qmVH9T0M8eQPNtC2l/WQh8uO+O+f+xFllH3zt qNWPU5Rvp1l/FOUd1dX6m2bab8JnDqLREQJHP/ZtNJYHR/Tg6Norrqxau3b3nj2uVHnksS36hXMe J7M2YenK7B2bOn4xpirI/HzAsmP0/wnB4/ahIB19Ag+eRF1emnZ9wqh2umtSLlwqu7wadnktAOcO 6CZU7U34fdStCDKfxce8FZ+Thec7U098DMB9nX6Kz50P1Oejwj7mePqon2Kl/ZHz4TYf9o0NsrgA dVGCJ4JkaXBrsDmYC/JBLaF0qg76BdOockQ5pvBKQXUonaojH5VWWSyaPp9pDIX5KAoLCitjA+eF Bmjw9+fOCOgQliVQm85/SgqEKMjrNqvdSnPI6EcIwCHhtRCyyg4zFFhZuQZ0MNybH98sS7JwoI8J BAsNcnXXf3D5E+N0S4vFcdWECXcObHm45eLF4/osJ/d07L6j1/AJE+/aQNI0bAr0CdJ4PtBHxd/m cwd8goxUWcRiZ4piKZtJ1SPVNVORJSq+1EfAqMSRVinCWx1pBRzOGpmuCGDdbtji/FalQQ0lEqtB 5bBi1qdSkqhBXljB3ifGjeXda1AUVnatApUrSTWN+qgXo+HqFDyF1MtTlbl4LlkgL1BWoWvwNWS1 vEq5Rl2P15N13G3SBnmj8gh6QLlbfQE9rr6CXpJ2qm+i36qfoA/U79Bf1TPopFoFzVH9yKuWo6Ta Tx2HDFURDKe3RgBmqSl8K5XmZ4rUqKBMZWcJo4ihKO0LeowZtbRX2FEiCJqFJgh9loK+geVQ6lAK 9ehM5OynSrKcUFS3oqiIIyRhZvgJqopUM11PlFSFQ1jooWGtRDYMQ2lSiNKKQ3sMoUkgApQMJUoM XGL59l3KT+3BQEemIxP0tx/P5D+61BlhdKTPn/BHc57z+Uld0vdZPiVLn3NVY/xi9sr/Op4o9qe+ 25e9ik92rJ23ZNJKsoGxB50+hZDwEvCHky8qzFt1UguVIZCZFibmfY332ec/eZaRTEuOqGaeaGux mQMEoF5pyWGwfdXBYaSBTYRFO/SHVWOfo9EcmPAq71DzkSoT7Bz0Q2CH9A8P6e+zKaz5rEvWvsK8 tRBIoRtX8hUqGem4zHGng3NEzU9R5j+pxxcKDgo9SnGsRg8XmTFs46Xi0hpe1BSXGPo/jV0LdBPX mb73jjQzGs1oRiPZlm3ZIz8kG8vBjm1iBAoeOzYGFGKDDVjGvEJI8yAL1DyaHBZEmkfTPOimPYSk 2ziluw1J2kWWiSNMzjFZsiRxHtBNSnbJA5LQNuk5lCRLklKKtf+9GhvSZc/pyN///3Pvf+fxzz/3 Mb4PR75utyEb73Q4XaKuIQ/nFfxiobMI2rJBoUoMuxrQNGGGONPVyrXzpjBfjDmvU9vd8/Sl6kL9 duEm8Tv6nfxdwkbxAD+iDutf8RcclU53JapUKlyVaoVe452OGvUt4n3ibu4x+Wm8l+x1/lJ+Hg3z I65Xbcf5/3Z8avtU/YN+jv+Lw+9ko0JkRjU+23GPFeuM6pbjFkou1aYjtyiIQUENumhzziVwCpaD Sjpz3GykOZUC/lfF2mwK9np4yekOSWF3t22h1Ode697q/qFbcks28Eb6OLIP5m87uNaEz9Vku9Zr p+kvWwOAv0LTy7GOr4LdIUkitFUkze2GPD42ZEc61FvmmjdLqitw2C2IAcGt62G74LXbBRc856Di 8iqKS4RmT1gSvZCc9oa13hVEsKDbRNUtuxR2eTrk5XTmE/ry6CodKyd5v9YUTKdYSCicksZPm1Kg Q8LrpO0SkdJkkenocON17u1u2gl9kenU7Hgl+2bMwev19PP4a8/XN7NqUf78c8uW+aBuA3/0NVvm u3JPWOu9czP6d3SEFVxalILKFLGk0dWzXwnIAfJi5hTUa08hV+bYflSrBnTw0cnZ4eKxZEMXGyl+ bFCgk8ZBQElXLFnPui2JmVODQiAbqlujeunwm2PDUB2EY0N+dSwl1NIjptB0MpI90+TBJ9PlsXTu zKkhKWALoOlWL1trMM87w3oEVetsCNygh372j1/60s3GArERvzRLYTmKJ491x+UqOBwbPzjyTJOt /pkDA9OuHd43vv/gM1PehSzmp6fdY+QfLu5+/U1y84UTZOvzfz3K8hoVyqIvIK/R8PtWWZSjYidv Iw6e8Ar4pMrq5WpNmLklm8Wo8AVVx2ppfnZCgc78SK+6y7ZLfNz1hHrIfog/JLyuOlQzN1LAeRw5 SoE2Dc9w7sCPOMUafYktLsSdPa7H8G5pt/MFkpZfdY653tBOcL91/EZ5T/udpE+8Xk4Z6W7Vp0D1 go7gMl1UUnlEFCRJhGfDealTQEaU7QZ+M89zguhwYJ532G0cVPxUKNUVrKqK5oSqBVGcnKxJvEpU STuCjjiIFkQOL0IOjihHFKwEZc4ry5zkcHAc4aE9IMtI6tCxPlfZJpdK6iresc2UoHR4weQ7+QSb Mu060xXgtpHSDrDlXPfWl62Zp1mBAeWF9jvt3Bk2S8Elj2bT3Fv+usyahjWiqveLzE+zFBh13qgY tdxiv8tXFHGy0cVFEbk0L8IB6H6qJKKxMRo5EVxaEnGY/snJHOLsEyr7jxEUOvV5tPhppP8r4iqw iu8Zf/yjX0z1VweH3h3/J/zgBydmjH9GKvH4+fbalvoL4/LFt/C8+PgyuK+S8QXcn8BHCvA3lo8U SV6Vc3L+fFXnnbzH1NWA05QDlq/k14QLPijwvVmQr1HGGuus4CgcUv1YpTdxhz9S6V2s7pM4UzHh gQQqaxs0SgTZoecqPr3CWSFXKNfI1yjTXI+7nZV6pWdOblyPe+I5t+q3em7NuZPfrNzpvst7V869 yg/dD+kPeR7w7pb2Ol/UDrpHvH+U/uD9Srmonfdm/MUTHpXrcfoLbWqreo/KqfmTl5/9mKBPDido VFVZg9wSag/5Xo8nqEte2FFlyA6DTgkaw5KHdiN38vQAyK/5SY1/1E/8adL0vAq2ML1p0m06m3RT Jyv0UZ3oadwyrOJS1FYo0ShmLTMg18odMtcpZ2Qig8ZQjQq2IU37CwNbIWsE412kc+eBE9HZBnza udP5dL76MwU+7QyTkI82HyY8Srz8H5zUpe5n/gP5ngvyGx/kNweRnPkUOTOf4stzG2/mw+HGiFTa GHHBW/Z8TsRtDRiM01oznQIE3MdTke3z0si6/1vVGDoVelnpdu/M6uicPHfI7hy/498/CJca4U/2 j69tLq/durhh/DvPaJXlhberRbbKi49v2rF1M7n9wqv7WuJd9JtgF/c/pNf+NnLS1pzZN5C/L5+c Fc56yEnhpIccFY56yKgw6iH7hH0eMiAMeMhOYaeHbBO2ecgF8YKXrBXXekmv2Oslsih7idcjCtD+ cCJOPe/izhOXQrAcVVCUzs3badZ41gnbhZ0CJ2DPdG/UpchRKMrMvIIG1yYsTBejBKMox+0kmOT7 NjydbbSzXgTaxdNsKnkmoSY6WPuMxuZ5sabCpKUxoiN/oXL03Q0bNuAN1oaX4ZwyNtlkHs8LJZfJ 2PtSoGppdWMDh38yIdle/s2/3hftnDI7b+mSSxL7Bt7OfUZusL/GbPWeeQOz1efi516CRewlp4RT HnJMOOYhh4RDHpIUkh6yR9jjIY8Kj3rI3cLdHrJeWO8ha8Q1XtIldlm2UmUnh7zPeah1ZAWM5gJz YfE5gQbUYjAhQVGMXWpUBotVKHmzZFmhBlM2EcJFERitAtGRLbcxe0HOF6UfmKPMWKc1JrNZOOmy JhP82+aatNSGDWC5bI8Lr5Bd96T+MnnJS0Z4afU107j/mhBsfwYTzVwwpT13RdcliZZpa7nP8LXM VhvN0NvCJwIZFA4L5EsR/1j8uUj6xbtFskhcA00BEYtgAeuGi9kNYyfcMpq8O3Z7+fLP7px0B+uu Ll6+XAuaePD0yV9+C1uvdLXZJUs5+c280fDvV6jRr8RCka0Id/jOC/YJTnvXCJvt9POkY3KJU+DC rPEb0HUa+su+8XptxmTMxDabR9m1/MizaCtDBD0LvBn4CA239aNFgJOAKGAxoMAKmw9YBegCvQO2 X6H1IPfaF2cu2hejXfZX0M2AJ0HeY/sE7eUj6A7Y/xfQHaXxoLuLfxbthrB/hrjVEPYk8B7Y/znI fZCm1pIdwsMoH/TnAe6zIdQJfDYgBsfyAG8B3I9fQT/Ar2T2QDxw9H049v00HNBq8TlwX/dCfBOk K4f974NcAOfggauAEojvArRD+rV0LVv4bUZjmMdVeA5OkOXkDe5j2zF7gl8uzBOeEv/o8Dn6HMel Xzm/J+fKI4pf+Z7LdL2sXqMt1HbrUz02z5Pe0hx/7sK8vT7kezT/+oK1hcf9R4qeKr7L6IVq3F9L 3iqdU/pOeaD8yeBw6ImKrZXLp1RN+bfw3dXe6tNXnautujpad0vdeP1P6n9vLVs7G9P5R1cjO7zh GqpBi+H5KFIGwgjT0K3nyyMXQotbO5f0XB9u/u6tq9bO72YasGUq6JxLV9hms7lNnUiGOh5dCldH dG7LHJQLOYiPrZ1ZiIpQCSpF0MRCIVSBKtEUVIXCqBpNhWupRVejOlSPoOEFdmtE01EEzUB05drZ qB3NQXPRPBRD16P56AbUgTrRArQQdaFutAjuYgnqQXHUi5aiPrQ/u7LlYLfaXMrlobOADIBDBtAa QAdgBWAnYADAI9UKWQfYDhgFfM5iTC4v9Wi9mQb2IGNDt62tY7ursrt9y9ju0JJ4ls9fkOWtc7Nq M7JqVzdkg6e2ZHlFdZbrwboE5ZJSd6g5l8tFxwAErQeKyctIhcaRgZ7iclASQDjeCjE5fag8VDcw ytkQ5gi0sW9CRuYQh1OKu65ZIhlyFuxvkD+RM9kYcmbI5a4baJ5HPkb7AKMAjnwMv4/IR2g7gWYD 0oA2AQYAo4CjgLMAnpyC30n4fUg+RCr5ANUAmgArAAOAUcBZgEA+AKqR96kbMUrlJgAh7wPVyHtw W+8BVckJkE6QE3Bpb6caI3UHmBCusQQjaAl5hZag59alyX+mzk8x0uSToUDYeKq5lryDkgDwTKAa IADoBKwErAfwIB0H6ThKAH4EeAqQBPCQ5jikOQ5pxgBvAI6jWoAJ6ASI5FgKTpMmR1OhFqM5l7xF XgFXNsib5FXG3yBHGH+d/AfjrwEvBj5GjqSKDdTshHgEaTTgGvAaiLeTl4bKdSPT7CajYB4DaA2g CdABWAHYCeDJKClN3WTocJCDaAxya4Ok0GeM/xLtEZF5m2GGrgMfC1ASmnEtSEAGAgMhYoZ2PQ67 lIQeeRQkSkL3PAQSJaG7doBESWjtZpAoCd10G0iUhHpXgERJqKMbJCBp8uQL5RVGY8ftONCski1g pS1gpS1gpS3IRrbQHzpvo9f201RVFVjsCTM8pcpIjODEizixECf24MQanNiGEztwIooTy3EijBN+ nCjGCRMnDuLpYIoENvd/azdi+nBiDCd+jRP9OBHCiSBOlONEADeaaVKSmlvPWBtjQ830vQJ+7aw6 Fa6xBCxaAm5dAq/9KNCjgAzbM0EpUJpVzi+mvHSoqim7P3VG3brmOeQwJDwMj+EwOgmwwQM6DG50 GA5yGA6gAm0CrAAcApwFZAid9PwkKYUL38moCrQG0ARYAdgOOAvg2eWcBRC0zrrEfezCaqyL7qB7 5DD86JLGJaTELNL8Wlibw+2Etkwx7ijOFJNGlJtL1xp3i+40Voa/Uf78jYIczQ7yCNkJmaxBfmTx nanzRUYa706FDhrNOfgxVGwDr8MRFMJB4NNRP9ufhvwi5Q3IT54DXpfyL4ZkaipUbYxgF001bJz3 nzY+g1YHiJ/6DxrvBtI2nDJ+CyHPDRvv+B8wXqtJixDyYiiNgY0EmOoB/3Tj12NMdQdEPJEytlE2 bPyjv9243c8i1mQjlvfDnqkaC0O9xhw4Xqv/RsPsh2MOG03+5UY0qzWNphk2auESwlmxCi52ip+d tKyYHXBRYxrfYlYLu4QeoUO4RqgTqoUSwRCKhELBK+qiJrpEWZREUeRFm0hEJHppZ/YwLQO9vMY+ itootTFZI5Rmi0gENWACRVHSw8VIrKsFx5KHVqPYjYHk111laSwt6E3ay1pwUo+hWHdLcno4lhYy C5ON4VhS6FzaM4jxI3EITZIfpDHq7knjDA26t5CuxnoAYey+9+FCyivvfTgeR77czU2+Jn2WOzK7 9QpkpUUv+/Tr+5ZclNwV6+pJPlsUT9ZRIVMUjyV/TJdrPYC/xJ+3tR7AX1AW7znAzcJfti2k4dys 1ng8lsaLmR7USL8APfCYL5ieWIwCVA8FxOKs3hNZvSCkB71yykDP4UBBphd0OJieDVO9wf7yttbB 8nKmkxdA/UynPy9wuc5YEHSCQaaTm0BjTGcsN0F1krOYit8PKsV+poILkJ+p+HEBU1l8SaXGUnlg UuUBdiYOX9LxZ3WUUxM6yinQCf+925qWcBgPzYyv7qNL3a4sa1sDWJl8cPMtvmTixkBgcHXcWgM3 tPLG1bdQvmpNMl62pjW5uqw1MDiz7wrRfTR6ZlnrIOpr6+4Z7DPXtKZmmjPbyla1xofaOxsav3Wu BybP1dB5hYN10oM10HO1N14hupFGt9NzNdJzNdJztZvt7FyI+Xhnz6CIWuLQgmd8iDgl8NeVhSXx llxt/SzmvDNLfNsKR6BCshc5w/GkXNaSVAA06qrmq5ppFLxTNMpF1zO2onzbZpYUjuC9VpQGwe6y FhTeuKl/E/K13dqa/euHDYI2bqIGz9Jw//+3QVxb0lzV2r8RoViyqiuWbFrQ2zMoCBC6kt5ScsZE mNPZls4cygZOhcAZNJDjJhVpWJSGORyW4v99/psuzYd6ACoaB4cwtO02ov44lyyOdRPICrqthWNH oLpEi4f+ONxgPw7j/oljsMu2/tGB6P1OYOMmS7LssNHi2VSQpH/CHJMbtRL6X6P3RpkKZW5kc3Ry ZWFtCmVuZG9iago0OSAwIG9iagoyMzA0NQplbmRvYmoKNTAgMCBvYmoKPDwgL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yIC9Bc2NlbnQgOTA1IC9DYXBIZWlnaHQgNzIzIC9EZXNjZW50IC0yMTIgL0ZsYWdz CjMyIC9Gb250QkJveCBbIC02NjUgLTMyNSAyMDI5IDEwMDYgXSAvRm9udE5hbWUgL1ZEUFdYTCtB cmlhbE1UIC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9MZWFkaW5nIDMzIC9NYXhXaWR0aCAyMDAw IC9YSGVpZ2h0IDUyNSAvRm9udEZpbGUyIDQ4IDAgUgo+PgplbmRvYmoKNTEgMCBvYmoKWyAyNzgg NzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDMzMyAzMzMgNzUwIDc1MCAyNzggMzMzIDI3OCAy NzggNTU2CjU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNzUwIDI3OCA3NTAgNzUwIDc1 MCA1ODQgNTU2IDc1MCA2NjcKNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA3NTAgNjY3 IDU1NiA4MzMgNzIyIDc3OCA2NjcgNzc4IDcyMgo2NjcgNjExIDcyMiA2NjcgOTQ0IDc1MCA3NTAg NzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDU1NiA1NTYgNTAwCjU1NiA1NTYgMjc4IDU1NiA1 NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzgKNTU2IDUw MCA3MjIgNTAwIDUwMCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUw IDc1MAo3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAg NzUwIDc1MCA3NTAgNzUwCjc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3 NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAKNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1 MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MAo3NTAgNzUwIDc1MCA3NTAgNzUw IDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgNzUwCjc1MCA3NTAg NzUwIDc1MCA3NTAgNzUwIDc1MCA3NTAgMzMzIDMzMyA3NTAgMjIyIF0KZW5kb2JqCjYgMCBvYmoK PDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVkRQV1hMK0FyaWFs TVQgL0ZvbnREZXNjcmlwdG9yCjUwIDAgUiAvV2lkdGhzIDUxIDAgUiAvRmlyc3RDaGFyIDMyIC9M YXN0Q2hhciAyMTMgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iago1MiAwIG9i ago8PCAvTGVuZ3RoIDUzIDAgUiAvTGVuZ3RoMSAzODY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp42q1Xe3BU1Rn/zjn3lWRDNg9Cyqrc5ZKoZMNTTAQMS7K7JtlaEhLKLmrZzQMTCBKB yRClTCw+cBM620qd0SoEFQxI9C5BDQztUBTMjHYsM9rRYrWdiaNjjTO2Ik47mP7uvUkGtDr+0fvl d3/ne9zvnO+cc/eeECMiF3WTIH/TxngHabQEljeAgqbOrfrAV4diaI8Qyb51HXdufPWLJSaR4iaS 1t7Z3rUu859t8Kd3IGZ7a0u8+RPv7r3QP4V+YysMOblpzxNlzII+q3Xj1m3qIVYCvQq61r6pKU7l VAS9FrqyMb6tQ7tV/Sn0CHT9rvjGlnBv54PQt0Gf2bFpy9axpdQM/QnoRR2bWzpWvHbtWuivEokG 2BhZ9VgVKQCRd9Lyf7rGvuP6oU/azXPfGTQf0sQi/D6+Bq3fUiPujwPNwGO0h/bwQSeGFgImWjX0 kTxMC2izbV9I23EP0Fesnx60LUupEf5GRJ8Bl8PXBGZ2jj2s1+af0/3I/Tkf5Kf5adu7DHlrrAhH +KA8DLuVbyc9T++zU4i5lx6B7zids55C5j00QBfZdZAe9iEb5bWwMqt/5NmA6D0Y7+/pXfoXy2Pl LMFOIiaH32ePxemtGzFnIOfsLJbcytrZJraZPYycI1zwRci6ie/ifdzkp0VUKpeHlRylVG2315lj F2ejQivbT6gePTfS3ZNZHfkT46yONbBW9ijrwxjOsFHIF7yEL8OsW/IbEZNc0sfyBvkpyLCySn1S U5Bbxp6aTjoV0g2oKog+6jDmZlpP99hyL2Q75vIXtI/6aD8dohSdoD9YfdJ5ep8uYnayIFZdpewm thoShWxmO9j9mI+ey2Q3e4INshMY3+vsbT4DVTvSjuqdUe7kj/Nj/HX+Bv+Aj/BP+OeCRJpYKxrF FnFAHBZvijelKqlP2i+9J70nM9m0ZypHyVPuUHogvWqaukG9X/2V+qT6Uvocmoa6fKirhlajqi5U sp12UcJetRTkGL0IGaZPrDogY+OVWHITC7AQWwWJsjUsxjayLWzbZEXPsIOsnx1DLW9D3mHn2d/Z P9hntlzkCs/nxZP11fJ6vppv4I/yx/gT/DnsyEF+kr/D30eNI/wCaswQOWKquEYERQjSIG4T28RO MSBOi/NiFOvmkm6WyqVV0h2o/aw0In2MleSykAvlRfJiSKt8l7xD7pH3YkePyqOKy56VHCVXWaI8 pOxTBpV3lUvqVDVfnQmZo85X69V2tVM9rI6oH2lH0pantaVtTvfRYZpHL3/j7X0Ru/sVfocyl6az 89gNd4ssROnWu8ddantaGx+0RqfWs+uwUn+liyKNwtJZWi1uo3a5UWSon1I/2yLdx54TITpCB9RO dlLExKg4IBcqS5z55I+Lw2qXGlM/wki/EI/IreoctlzuYf18Gd7ozayOvmQX6GfoeSufTWfpYdrF OvG7vkc7wjLxrp3hM1iP/JQ4KvWJoLyDXY8V9MjD4gFaRFP9pWWlNyxcMH/e3DklvuLZ1193bVHh LGOmV59xzdVXeab/qGBa/tS83Jxsd9aUTFdGepqmKrIkOCNf0AjFdLMoZkpFRlVViaUbcRjilxli pg5T6MoYU4/ZYfqVkX5ErvtGpN+J9E9GMre+lJaW+PSgoZt/DBj6EFtTF0F7d8CI6uao3b7VbktF tpIJxevFE3qwoDWgmyymB81QZ2siGAsgXyojvdKobEkv8VEqPQPNDLTMkNGRYqFyZjd4KLg4xUnL xKjMGiMQNKuNgDUEUxQG481mbV0kGPB4vdESn8kqm4xGk4wKM6vYDqFKuxtTqTRVuxu9zSqHevSU 71Sid8hNjbFiV7PRHL89Yop41Ooju9i8xQiYt9wzUlDiG2IHGyJmWuUQo4bIcaoZ605VdwcCUau3 nMrIQ3b4NIRPu2fEIxLBgjbdUhOJh3Szry5yuddr3aNRJC3xhVdGvBi1EezVrTJWRuwKkJQVzMUg LZtVplNwixG0LLH1uplmVBitifUxLNb0hEkru7xHp9f4j4/9jWqCeqIhYnjNZR4jGg9clcqjxMqu wWq/Xn2lp8SXcmc7M52akjXecGVe3miZ9NktO9xqYdQTU82sERnV2CKm3qRjJBHD5IVl1q2ljBJN ZQjDFWWY0TbMXyzhXmwthFzoNvTEBcJGMEY/vdISH7cohe4LZDWt7TK55eCfaJvFxebs2dZOUSux tBhZua0vKvF1mmGjw62bYUwZ1UbwUHTxXEy512utcs+QnxqhmN11EUfXqdFzlPxzi6Mmj1meUxOe qassT/eEZ/LxmIHtfMw+5kw1taLJvyx3fm6wdbHJ8r/H3eL48foE9ZQkFyZqI0XxRI+nKJbojWJp QngVE4mQoYcSsUR8aKy70dDdRiIVDic6grGJkobGTvV4TH9vtJVhUs2FzmyYuZUR4eFRp8U9Ioqj H8f3mEQ3ThOCVDL8WepbTHqLPY0D5RjJY+I4+5Bo7tej7lFa9hnu8+ctzPZmF3qzvd2CLnVz+prk 4X+XdUvD1mlvgJ3klyQXcuX9jhgvRZGCNSHBKP7mz8vFowO8FkG1l0yy54D9+PX15xRjbdbSC+TR 7J/tV7r+I0/yxOisM+TEyRGszv8aZ9SMXpzj3kz/4FtnSi4RdYtDOAHhXIqzkNMXZy7Uu5um4O6m PHxdSf1YPohzhD0SyhnPo8BLDSvqgiuqi1e33XVnM7DFen785FhmnXn/xzXu97soFALnZGv+Kn2I 33i0agFop03siEPPOXTIoX6HnnXoaYf2O7TPoWqHqhy6xaEKh/wOlTu01KGbHFIckhwSDjH/CvB7 wHngL8CfgVeAl4AXgReAAeAI0A88C+wD9gJPAr3ATqAJWGvnfMFJPeDQYYcOOnTAoWcc2utQwKHl Dt3sUJlDqkOyQ9wh8vvB7wJvA8PAa8BZ4AzwMnAMGASeB/qAXwNdQHPVgry0vLTS5BDr9Feryf1q 8hE1uVtNblKT7WpynZpsUZO3q8k1ajKqJiPqLG2mpmvXaFdp07UCLV/L03I0tzZFc2npmqYpmqRx DZ9wM1eEebi+goXNU00UbtTNL+uNIZZet8aUjQpm5oQp3FBRYJYVm3yX/YUYYmMpxn75gMf6OBwn xsYe2O0Z52iU8ou/fRVcoYVru07SDFaKl3UGWzioznhVtaz1sCZta9KyJm1rATtaSwvC8Z7Y1VT8 fRcr/qEXC7ZZ5dZGUhpVRCtvd3iQZ6SjnpjHG63Id3eU28Ut8Rbs8JyQCP/6ZOA30oWPbiZguUqW lyy3XHhLLdcU63s87irYscTrOcH6x11umLMxlf8FziK/3gplbmRzdHJlYW0KZW5kb2JqCjUzIDAg b2JqCjI0NzcKZW5kb2JqCjU0IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50 IDg5OSAvQ2FwSGVpZ2h0IDc2MyAvRGVzY2VudCAtMjExIC9GbGFncwo0IC9Gb250QkJveCBbIDAg LTIxMSAxMzU5IDg5OSBdIC9Gb250TmFtZSAvVE9RRU9JK1dpbmdkaW5ncyAvSXRhbGljQW5nbGUK MCAvU3RlbVYgMCAvTWF4V2lkdGggMTQ0MyAvWEhlaWdodCA3MjMgL0ZvbnRGaWxlMiA1MiAwIFIg Pj4KZW5kb2JqCjU1IDAgb2JqClsgNDU4IF0KZW5kb2JqCjU2IDAgb2JqCjw8IC9MZW5ndGggNTcg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp42l2QTWrEMAyF9z6FltPF4CSbboKh TBnIoj807QEcWw6GiW0UZ5Hb11bTKXQhg/TeJ54lL8PzEHwG+U7RjJjB+WAJ17iRQZhw9kG0HVhv 8tHxaxadhCzwuK8ZlyG4CH0vAORHkddMO5yebJzwoc7eyCL5MMPp6zLyZNxSuuGCIUMjlAKLrqx7 0elVLwiS0fNgi+7zfi7Un+NzTwgd9+1PJBMtrkkbJB1mFH3TqP56VQKD/ScdwOQOZ9cqLtfoR/b/ KhWtX7xHMhtRScN34Bg1gA94P1WKqVJc348VcH4KZW5kc3RyZWFtCmVuZG9iago1NyAwIG9iagoy MjIKZW5kb2JqCjM2IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFz ZUZvbnQgL1RPUUVPSStXaW5nZGluZ3MgL0ZvbnREZXNjcmlwdG9yCjU0IDAgUiAvV2lkdGhzIDU1 IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAvVG9Vbmljb2RlIDU2IDAgUgo+PgplbmRv YmoKNTggMCBvYmoKPDwgL0F1dGhvciAoQnJ1Y2UgTG93ZWthbXApIC9DcmVhdG9yIChQb3dlclBv aW50KSAvQ3JlYXRpb25EYXRlIChEOjIwMDcxMjAzMTAyNzE3LTA4JzAwJykKL01vZERhdGUgKEQ6 MjAwNzEyMDMxMDI3MTctMDgnMDAnKSAvUHJvZHVjZXIgKE1hYyBPUyBYIDEwLjQuMTEgUXVhcnR6 IFBERkNvbnRleHQpCi9UaXRsZSAocDJwc2lwLTcwIHJlcGxpY2F0aW9uLnBwdCkgPj4KZW5kb2Jq CnhyZWYKMCA1OQowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwMDA0NDcgMDAwMDAgbiAKMDAwMDAw MDAyMiAwMDAwMCBuIAowMDAwMDAwNTUxIDAwMDAwIG4gCjAwMDAwMDA0MjggMDAwMDAgbiAKMDAw MDAwMTQ3NSAwMDAwMCBuIAowMDAwMDQxODMwIDAwMDAwIG4gCjAwMDAwMTM3NDEgMDAwMDAgbiAK MDAwMDAwMDY0OSAwMDAwMCBuIAowMDAwMDAxNDU2IDAwMDAwIG4gCjAwMDAwMDQ0OTAgMDAwMDAg biAKMDAwMDAwMTUxMCAwMDAwMCBuIAowMDAwMDA0NTk3IDAwMDAwIG4gCjAwMDAwMDQ0NjkgMDAw MDAgbiAKMDAwMDAwNjAzMiAwMDAwMCBuIAowMDAwMDA0Njk2IDAwMDAwIG4gCjAwMDAwMDYxMzkg MDAwMDAgbiAKMDAwMDAwNjAxMSAwMDAwMCBuIAowMDAwMDA3MTQ1IDAwMDAwIG4gCjAwMDAwMDYy MzggMDAwMDAgbiAKMDAwMDAwNzI1MiAwMDAwMCBuIAowMDAwMDA3MTI1IDAwMDAwIG4gCjAwMDAw MTc1MDkgMDAwMDAgbiAKMDAwMDAwODMxNSAwMDAwMCBuIAowMDAwMDA3MzY0IDAwMDAwIG4gCjAw MDAwMDg0MjIgMDAwMDAgbiAKMDAwMDAwODI5NSAwMDAwMCBuIAowMDAwMDEwOTE2IDAwMDAwIG4g CjAwMDAwMDg1MzQgMDAwMDAgbiAKMDAwMDAxMTAyMyAwMDAwMCBuIAowMDAwMDEwODk1IDAwMDAw IG4gCjAwMDAwMTIxMTggMDAwMDAgbiAKMDAwMDAxMTEzNSAwMDAwMCBuIAowMDAwMDEyMjI2IDAw MDAwIG4gCjAwMDAwMTIwOTggMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDQ1MTU0 IDAwMDAwIG4gCjAwMDAwMTM4NTAgMDAwMDAgbiAKMDAwMDAxMzUyMSAwMDAwMCBuIAowMDAwMDEy MzUxIDAwMDAwIG4gCjAwMDAwMTM2MjkgMDAwMDAgbiAKMDAwMDAxMzUwMCAwMDAwMCBuIAowMDAw MDEzOTMzIDAwMDAwIG4gCjAwMDAwMTQwMjQgMDAwMDAgbiAKMDAwMDAxNDA3NSAwMDAwMCBuIAow MDAwMDE3MjM1IDAwMDAwIG4gCjAwMDAwMTcyNTYgMDAwMDAgbiAKMDAwMDAxNzQ4NSAwMDAwMCBu IAowMDAwMDE3Njg3IDAwMDAwIG4gCjAwMDAwNDA4MjMgMDAwMDAgbiAKMDAwMDA0MDg0NSAwMDAw MCBuIAowMDAwMDQxMDgyIDAwMDAwIG4gCjAwMDAwNDIwMDIgMDAwMDAgbiAKMDAwMDA0NDU2OSAw MDAwMCBuIAowMDAwMDQ0NTkwIDAwMDAwIG4gCjAwMDAwNDQ4MTIgMDAwMDAgbiAKMDAwMDA0NDgz NiAwMDAwMCBuIAowMDAwMDQ1MTM0IDAwMDAwIG4gCjAwMDAwNDUzMTggMDAwMDAgbiAKdHJhaWxl cgo8PCAvU2l6ZSA1OSAvUm9vdCA0MyAwIFIgL0luZm8gNTggMCBSIC9JRCBbIDwyMGM4Yjk2M2Mw NDUxMzI1MDEzZWFkNGFiZWM1YWM5Yz4KPDIwYzhiOTYzYzA0NTEzMjUwMTNlYWQ0YWJlYzVhYzlj PiBdID4+CnN0YXJ0eHJlZgo0NTU0NAolJUVPRgo= ------=_Part_10823_16284663.1196707422812 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_Part_10823_16284663.1196707422812-- From p2psip-bounces@ietf.org Mon Dec 03 14:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGfz-0007nq-6e; Mon, 03 Dec 2007 14:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGfx-0007nc-VT for p2psip@ietf.org; Mon, 03 Dec 2007 14:09:53 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGfv-0003sd-Tm for p2psip@ietf.org; Mon, 03 Dec 2007 14:09:53 -0500 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1IzGft27MC-0000ab; Mon, 03 Dec 2007 20:09:51 +0100 Message-ID: <4754547B.5070905@tm.uka.de> Date: Mon, 03 Dec 2007 11:09:47 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] replication for p2psip References: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> In-Reply-To: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1+WcBLpCYR4NpTRebns8bIm6ynikWCBjqks2cl frzghOPSY3cdjHPcmEgCCcwW9PPsZBOmsVzdZWlE4yR0qKOffQ T1waY9wDvMdn3CdSLIGI71hyqwmG2Nr X-Spam-Score: 1.2 (+) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Bruce, thank you for slides on replication. I agree with mosts statements on your slides. Just a few comments: - Replication on neighbors is not always vulnerable to routing attacks. If you use iterative routing many overlay topologies allow you to reach all neighbors over disjoint paths. One benefit of replication on neighbors is, that you have a much closer relationship among replicating nodes, which makes replication by the responsible peers more efficient and secure. - "Who Replicates?". There is a second alternative for replication by the responsible peer(s). I suppose the approach mentioned in your slides is that the responsible peers pushes the records to all replicating peers. The second alternative (as it is done in P2PNS) is that all replicating peers pull the records from all other peers. In this sense there is not a single responsible peer, but all neighbors are equally responsible. I think having a single responsible peer is a big security problem. - I don't understand what we gain by additional replication by the application layer. In P2PNS replication is done only by the DHT layer and I would be interested if there are any (especially security) issues with that. Regards, Ingmar Bruce Lowekamp wrote: > I'm attaching a first draft of slides for the replication discussion > on Wednesday. (I'm also including the raw text below, which is a > little bit hard to read.) I have tried to summarize the important > concepts and issues, and at the end I propose a high-level view of a > solution, as I perceive the conclusion of the earlier email threads. > > I would appreciate specific comments on the slides, missing important > issues, or just general conversation on these issues. > > Bruce > > > > Replication for P2PSIP > Bruce Lowekamp > 12/5/2007 > 2 > Replication vs Erasure Codes > This talk discusses "replication." For > P2PSIP, where the primary resource is > a AoR->URI or similar mapping, this is > the right approach. For storage of > larger objects, mechanisms such as > erasure codes are more appropriate. > Most of the same issues of placement > and responsibility are still applicable > with only slight modifications. > 3 > The Questions > What should replication achieve? > What peer is responsible for replication? > What layer is responsible? > How many replicas? > Where to put the replicas? > 4 > Goals of Replication > Persistence > • Data retained after crash of responsible peer > • "Permanence" after storing peer leaves > Security > • DoS by responsible peer > • Routing attacks along path to responsible peer > Load Balancing > • Queries for a popular resource distributed > between replicas > 5 > Popular Replication Schemes > Neighbors > • Persistence with loss of responsible peer > • DHT-dependent definition > • Vulnerable to routing attacks > • Depends on responsible peer > Random replicas > • Fixed offsets or text addition before hashing > • Paths to different replicas are independent > • Harder to replace on loss of responsible peer > Query-path > • Replicas added along path to responsible peer > • Good for load balancing > 6 > Who Replicates? > Storing (owner) peer > • Cares the most about the outcome > • Should bear work responsibility > • Can't refresh after leaving > Responsible peer > • "Responsible" > • Easiest support for "permanent" resources > • Low overhead for neighbors > • Higher overhead for random replicas > 7 > What Layer Replicates? > DHT > • Appropriate replication scheme related to DHT > algorithm > Application > • Knows requirements > Persistence > Reliability > Popularity > • Knows when owner is present > • Only layer that can generate new signatures (if > needed) > 8 > Possible Solutions? > No single approach solves all problems. > Proposal: We need both > • DHT-level replication always appropriate, can't be > done by application-layer. > • Only application-layer knows enough about > requirements to justify/define further replication. > • Responsible peer needs to make application-layer > decisions about its resources. Not just DHT-level. > • Interaction between these layers may be useful to > detect malicious peers. > > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 14:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzH4r-0005tN-F2; Mon, 03 Dec 2007 14:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzH4p-0005t5-JB for p2psip@ietf.org; Mon, 03 Dec 2007 14:35:35 -0500 Received: from moutng.kundenserver.de ([212.227.126.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzH4p-0007Jo-26 for p2psip@ietf.org; Mon, 03 Dec 2007 14:35:35 -0500 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1IzH4g0DYS-0001cE; Mon, 03 Dec 2007 20:35:27 +0100 Message-ID: <47545A7C.7000300@tm.uka.de> Date: Mon, 03 Dec 2007 11:35:24 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Song Yongchao Subject: Re: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - VersionNotification fordraft-bryan-p2psip-reload-02 References: <000c01c8331c$eb5c6160$3e05a40a@china.huawei.com> In-Reply-To: <000c01c8331c$eb5c6160$3e05a40a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1+NgsJeyFUtV1PHb5yJUTlilat5RlSGkusyW0A 2h0FQ2v/OzHTkdcztIgCjAXBmnMhJeQvwahiZngi8AVW2ZyuK0 gZHi9DP5SO6q0SHPXeWUe8Nf4HQwaKM X-Spam-Score: 1.2 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'Jan Seedorf' , 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Song Yongchao wrote: > That was also my point. Replication handled by either layer, or either the > source peer or the responsible peer, has its pros and cons. > > However, for the peer protocol, should only take the replication handled by > distributed storage layer into account, either by the source peer or the > responsible peer. For the availability when the source peer is offline, I > prefer the responsible peer to do it. > > Of course, whether or not to replicate in the overlay is left to the > decision of the overlay operator. Is there an overlay operator? In draft-ietf-p2psip-concepts-01 there is no such definition. In my opinion replication is a must, because nodes can always fail. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 15:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHdI-00030e-QV; Mon, 03 Dec 2007 15:11:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHdF-000302-PM for p2psip@ietf.org; Mon, 03 Dec 2007 15:11:09 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzHdE-0004Pq-Mt for p2psip@ietf.org; Mon, 03 Dec 2007 15:11:09 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1IzHcW-0002Md-HA; Mon, 03 Dec 2007 21:10:24 +0100 Message-ID: <475462AE.5010606@uni-tuebingen.de> Date: Mon, 03 Dec 2007 21:10:22 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Initial slides for Wednesday References: <20071203050744.C50D033C47@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Henry, just few remarks: actually the paper that u referenced (which is well known in the P2P security community) confirms also that certified node-IDs are required: Section 3 says: "The performance and security of structured p2p overlay networks depend on the fundamental assumption that there is a uniform random distribution of nodeIds that cannot be controlled by an attacker." It may be also worth it mentioning that *observing malicious behavior* in a P2P network is not an obvious issue. and even if a malicious behavior has been detected by a honest peer, the honest peer may not be able to do anything against it. If the honest peer is, for example, undergoing an eclipse attack, the UA will not be able to receive phone calls, and the attack will not be noticed, until the user tries to initiate a phone call. But it all depends on the security requirements, and the deployment scenarios. (e.g. the size of the P2PSIP network and the social environment). If there is a requirement that "chosen location attacks" and "sybil attacks" (which can together easily be used for an eclipse attack) need to be avoided, then there is no way to overcome certified node-IDs. By the way, ZRTP can solve the initial contact problem, but it can not make routing in the P2P network secure. Hope this helps, Cheers, Ali Henry Sinnreich wrote: > Certificates are a critical tool, but are they the only tool as implied > in slides? > > What a about other schemas that may be more effective as the case may > be: > > At the p2p overlay, for routing, checking the consistency of the routing > table entries can tell us if there are misbehaving nodes: > > http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf > > Between the app and p2p layers, secure interfaces are also defined in > the above. > > At the application layer, I don't need certs for the entries in the > buddy list. Who is not my buddy (organizations) can be found and > contacted on the web. > > I suggest adding some words to the effect when certificates are a good > option and what alternatives there are, for what scenarios. > > Note: As H. Schulzrinne has mentioned, certifying a party that decides > to act with malice does not help with security. Observing malicious > behavior will do the trick far better. > > Henry > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Sunday, December 02, 2007 11:08 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Initial slides for Wednesday > > Here are my prototype slides for Tuesday's discussion. > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 16:08:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIW5-0007ro-4k; Mon, 03 Dec 2007 16:07:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIW4-0007po-5G for p2psip@ietf.org; Mon, 03 Dec 2007 16:07:48 -0500 Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIW3-0004t3-Is for p2psip@ietf.org; Mon, 03 Dec 2007 16:07:48 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8F73333CA0; Mon, 3 Dec 2007 13:02:29 -0800 (PST) Date: Mon, 03 Dec 2007 13:02:29 -0800 From: Eric Rescorla To: "Henry Sinnreich" Subject: Re: [P2PSIP] Initial slides for Wednesday In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> References: <20071203050744.C50D033C47@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071203210229.8F73333CA0@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 3 Dec 2007 10:01:13 -0800, Henry Sinnreich wrote: > > Certificates are a critical tool, but are they the only tool as implied > in slides? I don't think I said that they were. I've been asked to talk about chosen location attacks so the slides are only about that. > What a about other schemas that may be more effective as the case may > be: > > At the p2p overlay, for routing, checking the consistency of the routing > table entries can tell us if there are misbehaving nodes: > > http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf This is only useful for detecting certain kinds of attacks. And of course it only works well if you have secure node assignment. > Between the app and p2p layers, secure interfaces are also defined in > the above. > > At the application layer, I don't need certs for the entries in the > buddy list. Who is not my buddy (organizations) can be found and > contacted on the web. Well, I'm only talking about maintaining the consistency of the overlay, and pretty much by definition, that means connections with people you don't know well. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 16:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIyJ-0002Qu-5V; Mon, 03 Dec 2007 16:36:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIyH-0002Qc-Fu for p2psip@ietf.org; Mon, 03 Dec 2007 16:36:57 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIyG-0005wn-Su for p2psip@ietf.org; Mon, 03 Dec 2007 16:36:57 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4FEE322250; Mon, 3 Dec 2007 22:36:56 +0100 (CET) X-AuditID: c1b4fb3e-b1ea5bb00000459d-9f-475476f8c5e3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2D94B21D2F; Mon, 3 Dec 2007 22:36:56 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 22:36:56 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 22:36:55 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4D2FB2442; Mon, 3 Dec 2007 23:36:55 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8B3204DC3D; Mon, 3 Dec 2007 23:36:52 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 65DC14DB79; Mon, 3 Dec 2007 23:36:51 +0200 (EET) Message-ID: <47547762.9050007@ericsson.com> Date: Mon, 03 Dec 2007 13:38:42 -0800 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com><20071127220309.C632733C28@delta.rtfm.com><4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com><20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> <474EA5DB.4010201@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE363@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE363@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 03 Dec 2007 21:36:55.0508 (UTC) FILETIME=[A0243940:01C835F4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Henry, Please find my answers to your questions below. Henry Sinnreich wrote: >> the with-hip mechanisms can be embedded >> to the P2PSIP applications. > > This means that on the laptop I am currently using there would be two TCP/IP stacks: HIP implementations do not require two TCP/IP stacks. It seems to be quite common misconception that HIP implementations would require changes to the operating system and network stack, which is not the case. > 1. The native TCP/IP stack of the existing OS (WinXP in my case), > > 2. A 2nd TCP stack in the P2PSIP application. While this would work, > I am wondering about the performance and ease of integrating with WinXP > (in my example). > > 3. I would need to duplicate the expertise put in the existing TCP/IP > stack that has taken years to develop to where it is now. > > 4. Don't residential routers and other network elements have to > understand HIP? No they don't. There is no such functions in HIP which would require HIP-aware routers (or other middleboxes). -- Jani > -----Original Message----- > From: Jani Hautakorpi (JO/LMF) [mailto:jani.hautakorpi@ericsson.com] > Sent: Thursday, November 29, 2007 5:43 AM > To: Henry Sinnreich > Cc: David A. Bryan; Eric Rescorla; P2PSIP Mailing List > Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) > > Hi Henry, > > Henry Sinnreich wrote: >> Both David and EKR make some very good arguments, though I believe the >> central theme should be the existentialist topics for P2PSIP and have >> changed the subject title accordingly. Here are some examples: >> >> ... >> >> 2.2. Solutions based on HIP and other NG Internet technologies. >> >> What is the risk assessment they may actually happen and when? > > I didn't quite understand this question. Could you clarify what you > meant by this? > > I would like to point out that, for example, the mechanisms in with-hip > draft does not require global deployment of HIP-enabled operating > systems or anything like that; the with-hip mechanisms can be embedded > to the P2PSIP applications. > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 16:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ9Y-0004n8-Jf; Mon, 03 Dec 2007 16:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ9X-0004mz-1E for p2psip@lists.ietf.org; Mon, 03 Dec 2007 16:48:35 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJ9V-0006M2-OL for p2psip@lists.ietf.org; Mon, 03 Dec 2007 16:48:35 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSH009XTTWX8X@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 03 Dec 2007 13:48:33 -0800 (PST) Received: from s73602 (dhcp-17a0.ietf70.org [130.129.23.160]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSH009UCTWVRO@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 03 Dec 2007 13:48:33 -0800 (PST) Date: Mon, 03 Dec 2007 13:48:21 -0800 From: Spencer Dawkins To: p2psip@lists.ietf.org Message-id: <064301c835f6$39675780$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [P2PSIP] Routing discussion slides for this week's session X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David has graciously uploaded my slides to http://www3.ietf.org/proceedings/07dec/slides/p2psip-0.ppt. Please don't feel that you must wait until the face-to-face meeting to respond to this presentation passionately ;-) Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 17:02:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJN7-0007il-I8; Mon, 03 Dec 2007 17:02:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJN6-0007if-J1 for p2psip@ietf.org; Mon, 03 Dec 2007 17:02:36 -0500 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJN5-0000rP-Vb for p2psip@ietf.org; Mon, 03 Dec 2007 17:02:36 -0500 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Mon, 03 Dec 2007 14:02:27 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB3M2PnT001892; Mon, 3 Dec 2007 14:02:25 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lB3M2OFV018525; Mon, 3 Dec 2007 14:02:24 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 14:02:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Initial slides for Wednesday Date: Mon, 3 Dec 2007 14:02:23 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE391@namail5.corp.adobe.com> In-Reply-To: <475462AE.5010606@uni-tuebingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Initial slides for Wednesday Thread-Index: Acg16KWrWGIs+GfhRCOu+kP5mtfUDAADUvzg References: <20071203050744.C50D033C47@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> <475462AE.5010606@uni-tuebingen.de> From: "Henry Sinnreich" To: "Ali Fessi" X-OriginalArrivalTime: 03 Dec 2007 22:02:23.0754 (UTC) FILETIME=[2F0C0EA0:01C835F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Ali, I hope I was clear that certificates are critical, as you have mentioned as well (for strong security supported by the enrolment server) but they are not the only tool required, since there are also other options at both the routing layer and the application layer. > ZRTP can solve the initial contact problem, but it can not=20 > make routing in the P2P network secure ZRTP was suggested at the application layer. "The best protocol design is when it is so simple that you cannot take anything more away". Henry -----Original Message----- From: iinfe01@ri.uni-tuebingen.de [mailto:iinfe01@ri.uni-tuebingen.de] On Behalf Of Ali Fessi Sent: Monday, December 03, 2007 12:10 PM To: Henry Sinnreich Cc: Eric Rescorla; p2psip@ietf.org Subject: Re: [P2PSIP] Initial slides for Wednesday Dear Henry, just few remarks: actually the paper that u referenced (which is well known in the P2P security community) confirms also that certified node-IDs are required: Section 3 says: "The performance and security of structured p2p overlay networks depend on the fundamental assumption that there is a uniform random distribution of nodeIds that cannot be controlled by an attacker." It may be also worth it mentioning that *observing malicious behavior* in a P2P network is not an obvious issue. and even if a malicious behavior has been detected by a honest peer, the honest peer may not be able to do anything against it. If the honest peer is, for example, undergoing an eclipse attack, the UA will not be able to receive phone calls, and the attack will not be noticed, until the user tries to initiate a phone call. But it all depends on the security requirements, and the deployment scenarios. (e.g. the size of the P2PSIP network and the social environment). If there is a requirement that "chosen location attacks" and "sybil attacks" (which can together easily be used for an eclipse attack) need to be avoided, then there is no way to overcome certified node-IDs. By the way, ZRTP can solve the initial contact problem, but it can not=20 make routing in the P2P network secure. Hope this helps, Cheers, Ali Henry Sinnreich wrote: > Certificates are a critical tool, but are they the only tool as implied > in slides?=20 >=20 > What a about other schemas that may be more effective as the case may > be: >=20 > At the p2p overlay, for routing, checking the consistency of the routing > table entries can tell us if there are misbehaving nodes: >=20 > http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf=20 >=20 > Between the app and p2p layers, secure interfaces are also defined in > the above. >=20 > At the application layer, I don't need certs for the entries in the > buddy list. Who is not my buddy (organizations) can be found and > contacted on the web. >=20 > I suggest adding some words to the effect when certificates are a good > option and what alternatives there are, for what scenarios. >=20 > Note: As H. Schulzrinne has mentioned, certifying a party that decides > to act with malice does not help with security. Observing malicious > behavior will do the trick far better. >=20 > Henry >=20 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Sunday, December 02, 2007 11:08 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Initial slides for Wednesday >=20 > Here are my prototype slides for Tuesday's discussion. >=20 > -Ekr >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 --=20 Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 17:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJV3-0001RN-NP; Mon, 03 Dec 2007 17:10:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJV2-0001FO-4I for p2psip@lists.ietf.org; Mon, 03 Dec 2007 17:10:48 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJV0-0007K4-JC for p2psip@lists.ietf.org; Mon, 03 Dec 2007 17:10:48 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzJUv-00021S-3j; Mon, 03 Dec 2007 23:10:44 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IzJUr-0007iT-3q; Mon, 03 Dec 2007 23:10:40 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7ED432FC070; Mon, 3 Dec 2007 23:10:36 +0100 (CET) Message-ID: <47547EDB.6000300@tm.uka.de> Date: Mon, 03 Dec 2007 14:10:35 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [P2PSIP] Routing discussion slides for this week's session References: <064301c835f6$39675780$f7168182@china.huawei.com> In-Reply-To: <064301c835f6$39675780$f7168182@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Spencer Dawkins wrote: > David has graciously uploaded my slides to > http://www3.ietf.org/proceedings/07dec/slides/p2psip-0.ppt. > > Please don't feel that you must wait until the face-to-face meeting to > respond to this presentation passionately ;-) I would add at least two benefits of iterative routing: 1) Iterative routing makes routing more secure in case you have malicious nodes in your overlay (by doing parallel lookups over disjoint paths). 2) Some overlay protocols like Kademlia or Broose are designed to only work with iterative routing (because these protocols maintain their routing tables by learning form incoming lookup requests). Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 19:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLIW-0000Zc-OE; Mon, 03 Dec 2007 19:06:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLIU-0000ZJ-UE for p2psip@lists.ietf.org; Mon, 03 Dec 2007 19:05:58 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLIU-00027s-It for p2psip@lists.ietf.org; Mon, 03 Dec 2007 19:05:58 -0500 Received: by ug-out-1314.google.com with SMTP id z38so2484283ugc for ; Mon, 03 Dec 2007 16:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=P0ZQ6wGJsYAtQyJx96+tKticXnUOVJ/jnZzkblkN7Cg=; b=wFti904L1iUcfDO1FMLRndCUMGL1HWIC4tVKFkjmeRUKCbyaG/P4ixXOKpj1k3THCl0zszSJQ7RPJDaf/qhbMowhCH1BVZjaJX4iPJJpx6OGu2yl1jjqUnSk/QfpAOt+Ug/xvCr2MOxxW9Qe1w+y2RC6FCFdfweCH9jelb4kt2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=erB1O7mPgW7OU3EAle4h7BtVoh5C5H2d0pW3kPROqkEcMyfvcdpnrZqPEOOHvP3N/Wg03YpClnTEF7uWp0iCLlTNNNeoB8mj3UE6Oo7A7ybiujU6CXoEROh/PayM1kdFpcPVBBlt9S6462Yuilp8op+c/53u6IaJSxtlgsKgOLM= Received: by 10.66.219.11 with SMTP id r11mr89051ugg.1196726757454; Mon, 03 Dec 2007 16:05:57 -0800 (PST) Received: by 10.67.21.19 with HTTP; Mon, 3 Dec 2007 16:05:57 -0800 (PST) Message-ID: <618e24240712031605s58c4d2e0g23b09a795c58da39@mail.gmail.com> Date: Tue, 4 Dec 2007 01:05:57 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: p2psip@lists.ietf.org Subject: [P2PSIP] Routing discussion slides for this week's session In-Reply-To: <618e24240712031601q6d2ea4fdpc46a0cd06196c3a8@mail.gmail.com> MIME-Version: 1.0 References: <064301c835f6$39675780$f7168182@china.huawei.com> <618e24240712031601q6d2ea4fdpc46a0cd06196c3a8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1023583740==" Errors-To: p2psip-bounces@ietf.org --===============1023583740== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U29ycnksIEkganVzdCBmb3Jnb3QgdG8gY29weSB0aGUgUDJQU0lQIGNvbW11bml0eS4KCi0tLS0t LS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQpGcm9tOiBWaWN0b3IgUGFzY3VhbCDD gXZpbGEgPHZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbT4KRGF0ZTogNCBEZWMgMjAwNyAw MTowMQpTdWJqZWN0OiBSZTogW1AyUFNJUF0gUm91dGluZyBkaXNjdXNzaW9uIHNsaWRlcyBmb3Ig dGhpcyB3ZWVrJ3Mgc2Vzc2lvbgpUbzogU3BlbmNlciBEYXdraW5zIDxzcGVuY2VyQG1jc3ItbGFi cy5vcmc+CgoKT24gMDMvMTIvMjAwNywgU3BlbmNlciBEYXdraW5zIDxzcGVuY2VyQG1jc3ItbGFi cy5vcmc+IHdyb3RlOgo+IERhdmlkIGhhcyBncmFjaW91c2x5IHVwbG9hZGVkIG15IHNsaWRlcyB0 bwo+IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA3ZGVjL3NsaWRlcy9wMnBzaXAt MC5wcHQuCgpHcmVhdCBqb2IuCgpJIHdvdWxkIGVuZm9yY2UgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBQMlAgYW5kIFNJUCByb3V0aW5nLCB0aGV5IGFyZQonZGlmZmVyZW50IGFwcGxpY2F0aW9uIGxh eWVycycuCgpUaGFuayB5b3UsCi0tClZpY3RvciBQYXNjdWFsIMOBdmlsYQoKCi0tIApWaWN0b3Ig UGFzY3VhbCDDgXZpbGEK --===============1023583740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1023583740==-- From p2psip-bounces@ietf.org Mon Dec 03 19:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLrO-0004Co-Tu; Mon, 03 Dec 2007 19:42:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLrO-0004CM-7W for p2psip@lists.ietf.org; Mon, 03 Dec 2007 19:42:02 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLrL-0006A7-Uw for p2psip@lists.ietf.org; Mon, 03 Dec 2007 19:42:02 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzLrI-00062w-PI for ; Tue, 04 Dec 2007 01:41:59 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1IzLrF-00039w-R5; Tue, 04 Dec 2007 01:41:56 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6A33C2FC070 for ; Tue, 4 Dec 2007 01:41:53 +0100 (CET) Message-ID: <4754A250.3000705@tm.uka.de> Date: Mon, 03 Dec 2007 16:41:52 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: p2psip@lists.ietf.org X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [P2PSIP] P2PNS slides X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, due to the limited time in our P2PSIP slot, I've decided to already upload some slides about P2PNS differences to other proposals so we can start discussions on the mailing list. The slides are available here: http://www.oversim.org/chrome/site/IETF-70-P2PNS.ppt Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 20:14:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMN3-000564-EF; Mon, 03 Dec 2007 20:14:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMN1-00052c-4e for p2psip@ietf.org; Mon, 03 Dec 2007 20:14:43 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzMMz-000143-2j for p2psip@ietf.org; Mon, 03 Dec 2007 20:14:43 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00I5O3FB9B@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 09:14:00 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI001WZ3FBHM@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 09:13:59 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSI0026I3FAK4@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 09:13:59 +0800 (CST) Date: Tue, 04 Dec 2007 09:13:58 +0800 From: Song Yongchao Subject: RE: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD -VersionNotification fordraft-bryan-p2psip-reload-02 In-reply-to: <47545A7C.7000300@tm.uka.de> To: 'Ingmar Baumgart' Message-id: <00d701c83612$f2dc8a70$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acg146yejXLDwJ+mSb29maPynMq+cgAKybyw X-Spam-Score: 1.2 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'Jan Seedorf' , 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] > Sent: Tuesday, December 04, 2007 3:35 AM > To: Song Yongchao > Cc: 'Jan Seedorf'; 'Cullen Jennings'; 'P2PSIP WG' > Subject: Re: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD > -VersionNotification fordraft-bryan-p2psip-reload-02 > > Song Yongchao wrote: > > That was also my point. Replication handled by either layer, or either the > > source peer or the responsible peer, has its pros and cons. > > > > However, for the peer protocol, should only take the replication handled by > > distributed storage layer into account, either by the source peer or the > > responsible peer. For the availability when the source peer is offline, I > > prefer the responsible peer to do it. > > > > Of course, whether or not to replicate in the overlay is left to the > > decision of the overlay operator. > > Is there an overlay operator? In draft-ietf-p2psip-concepts-01 there is > no such definition. > > In my opinion replication is a must, because nodes can always fail. Maybe I should change "the overlay operator" into "smart implemention". In a certain application scenario, an ISP may deploy an overlay, in which all peers are powerful machines provided by the ISP. These peers hardly fail. Customers get the service of the overlay as clients. The ISP can determine whether or not to replicate in the overlay, or just introduce a backup mechanism, by considering the applications running on the overlay or by his own will. However, in more scenarios, peers are always involved in churn. Replication must be adopted in these scenarios. Best Regards! Song Yongchao _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 20:21:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMTD-0004dD-KP; Mon, 03 Dec 2007 20:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMTB-0004ca-0f for p2psip@ietf.org; Mon, 03 Dec 2007 20:21:05 -0500 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzMTA-0001mG-AA for p2psip@ietf.org; Mon, 03 Dec 2007 20:21:04 -0500 Received: by py-out-1112.google.com with SMTP id d32so13310501pye for ; Mon, 03 Dec 2007 17:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=UtnJ75dBPXBcAzfEXAn/MxSENH9PkGp0RWd8SE7Y+jk=; b=v6Qn7LAX715z9Y+3a46jbFO3F/ib4fBpmkv+Bz/rL1gmLe+BBVrGW1kPbP3LimTzxwGmjO1XTGC286MRoH37DcBJhblaNXsx+8JNroAzhuRqDX8HIsMnip4mZT7Md6TDxPRzJDRUx0pg1An8uHxXw/TMg+wzCv7u8o52xP57hek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gP0OZiXyrt0KnqK7Tdy0SCW98bdIQEecY9/T3xVAMbLPgr8Osqza3eK0rp/5tkUvU6tDWsw38H7fYZ6D33FLxlP/Vk+KpZbrHOE6riWoaaPP0Jd8uNzuBE6atfemVY7gAPEF16ebcbwx8Y2PykjkiYvgnlW060HRTanO2XrgmhE= Received: by 10.142.237.20 with SMTP id k20mr2345wfh.1196731263331; Mon, 03 Dec 2007 17:21:03 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 3 Dec 2007 17:21:03 -0800 (PST) Message-ID: <20d2bdfb0712031721k15ab322r6aec387407500830@mail.gmail.com> Date: Mon, 3 Dec 2007 17:21:03 -0800 From: "Bruce Lowekamp" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] replication for p2psip In-Reply-To: <4754547B.5070905@tm.uka.de> MIME-Version: 1.0 References: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> <4754547B.5070905@tm.uka.de> X-Google-Sender-Auth: ba0c511d14d2a53b X-Spam-Score: 3.0 (+++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1777543773==" Errors-To: p2psip-bounces@ietf.org --===============1777543773== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTIvMy8wNywgSW5nbWFyIEJhdW1nYXJ0IDxiYXVtZ2FydEB0bS51a2EuZGU+IHdyb3RlOgo+ IEhpIEJydWNlLAo+Cj4gdGhhbmsgeW91IGZvciBzbGlkZXMgb24gcmVwbGljYXRpb24uIEkgYWdy ZWUgd2l0aCBtb3N0cyBzdGF0ZW1lbnRzIG9uCj4geW91ciBzbGlkZXMuIEp1c3QgYSBmZXcgY29t bWVudHM6Cj4KPiAtIFJlcGxpY2F0aW9uIG9uIG5laWdoYm9ycyBpcyBub3QgYWx3YXlzIHZ1bG5l cmFibGUgdG8gcm91dGluZyBhdHRhY2tzLgo+IElmIHlvdSB1c2UgaXRlcmF0aXZlIHJvdXRpbmcg bWFueSBvdmVybGF5IHRvcG9sb2dpZXMgYWxsb3cgeW91IHRvIHJlYWNoCj4gYWxsIG5laWdoYm9y cyBvdmVyIGRpc2pvaW50IHBhdGhzLiBPbmUgYmVuZWZpdCBvZiByZXBsaWNhdGlvbiBvbgo+IG5l aWdoYm9ycyBpcywgdGhhdCB5b3UgaGF2ZSBhIG11Y2ggY2xvc2VyIHJlbGF0aW9uc2hpcCBhbW9u ZyByZXBsaWNhdGluZwo+IG5vZGVzLCB3aGljaCBtYWtlcyByZXBsaWNhdGlvbiBieSB0aGUgcmVz cG9uc2libGUgcGVlcnMgbW9yZSBlZmZpY2llbnQKPiBhbmQgc2VjdXJlLgoKR29vZCBwb2ludC4g IEkgd2FzIHRoaW5raW5nIHNwZWNpZmljYWxseSBvZiBjaG9yZCBhbmQgdGhlbiB0cnlpbmcgdG8K Z2VuZXJhbGl6ZSwgYW5kIHRoYXQgc3RhdGVtZW50IGlzbid0IHRydWUgaW4gdGhlIGdlbmVyYWxp emF0aW9uLgoKPgo+IC0gIldobyBSZXBsaWNhdGVzPyIuIFRoZXJlIGlzIGEgc2Vjb25kIGFsdGVy bmF0aXZlIGZvciByZXBsaWNhdGlvbiBieQo+IHRoZSByZXNwb25zaWJsZSBwZWVyKHMpLiBJIHN1 cHBvc2UgdGhlIGFwcHJvYWNoIG1lbnRpb25lZCBpbiB5b3VyIHNsaWRlcwo+IGlzIHRoYXQgdGhl IHJlc3BvbnNpYmxlIHBlZXJzIHB1c2hlcyB0aGUgcmVjb3JkcyB0byBhbGwgcmVwbGljYXRpbmcK PiBwZWVycy4gVGhlIHNlY29uZCBhbHRlcm5hdGl2ZSAoYXMgaXQgaXMgZG9uZSBpbiBQMlBOUykg aXMgdGhhdCBhbGwKPiByZXBsaWNhdGluZyBwZWVycyBwdWxsIHRoZSByZWNvcmRzIGZyb20gYWxs IG90aGVyIHBlZXJzLiBJbiB0aGlzIHNlbnNlCj4gdGhlcmUgaXMgbm90IGEgc2luZ2xlIHJlc3Bv bnNpYmxlIHBlZXIsIGJ1dCBhbGwgbmVpZ2hib3JzIGFyZSBlcXVhbGx5Cj4gcmVzcG9uc2libGUu IEkgdGhpbmsgaGF2aW5nIGEgc2luZ2xlIHJlc3BvbnNpYmxlIHBlZXIgaXMgYSBiaWcgc2VjdXJp dHkKPiBwcm9ibGVtLgoKSSdtIHNvcnJ5LCBJIGRpZG4ndCBzZWUgdGhpcyBpbiB0aGUgcDJwbnMg ZHJhZnQsIGJ1dCBJIG1heSBoYXZlIHJlYWQKdG9vIGZhc3QuICBXaGVyZSBpcyBpdD8gIE15IHVu ZGVyc3RhbmRpbmcgZnJvbSB5b3VyIHN0YXRlbWVudCBpcyB0aGF0CnlvdSdyZSBoYXZpbmcgdGhl IHBlZXJzIHN0b3JpbmcgZWFjaCByZXBsaWNhIG11dHVhbGx5IHJlZnJlc2ggZWFjaApvdGhlciB0 byBtYWludGFpbiBwZXJzaXN0ZW5jZT8gWW91J3JlIHJpZ2h0LCBJIHNob3VsZCBwcm9iYWJseSBm aXQKdGhhdCBpbiBzb21laG93LgoKPgo+IC0gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgd2UgZ2Fp biBieSBhZGRpdGlvbmFsIHJlcGxpY2F0aW9uIGJ5IHRoZQo+IGFwcGxpY2F0aW9uIGxheWVyLiBJ biBQMlBOUyByZXBsaWNhdGlvbiBpcyBkb25lIG9ubHkgYnkgdGhlIERIVCBsYXllcgo+IGFuZCBJ IHdvdWxkIGJlIGludGVyZXN0ZWQgaWYgdGhlcmUgYXJlIGFueSAoZXNwZWNpYWxseSBzZWN1cml0 eSkgaXNzdWVzCj4gd2l0aCB0aGF0Lgo+CgpJIHRoaW5rIHRoZSBrZXkgcXVlc3Rpb24gaXMgd2hl dGhlciB0aGVyZSBpcyBvbmUgcmVwbGljYSBzY2hlbWUgdGhhdApjYW4gYmUgYXBwcm9wcmlhdGUg Zm9yIGFsbCBhcHBsaWNhdGlvbnMgdGhhdCB0aGUgb3ZlcmxheSB3aWxsIGJlCnN1cHBvcnRpbmcu ICBUaGUgcmVxdWlyZW1lbnRzIGZvciwgc2F5LCBzdG9yYWdlIG9mIHZvaWNlbWFpbCB1bnRpbCBp dAppcyByZXRyaWV2ZWQgYXJlIGRpZmZlcmVudCB0aGFuIGZvciBzdG9yYWdlIG9mIGEgdXNlcidz IGN1cnJlbnQKbG9jYXRpb24gdGhhdCB0aGUgdXNlciBjYW4gcmVmcmVzaCBpdHNlbGYgb24gYSBy ZWd1bGFyIGludGVydmFsLiAgRG8Kd2Ugd2FudCB0byB1c2UgdGhlIHNhbWUgcmVwbGljYXRpb24g c3RyYXRlZ3kgZm9yIGJvdGggb3IgZG8gd2UgbmVlZCB0bwpzb21laG93IHN1cHBvcnQgb3B0aW9u cz8gIFRoYXQncyB0aGUgcXVlc3Rpb24gSSdtIHRyeWluZyB0byBnZXQgYXQKd2l0aCBzbGlkZSA3 LiAgTWF5YmUgSSBzaG91bGQgYmUgbW9yZSBleHBsaWNpdCB0aGVyZS4KCkJydWNlCgoKCj4gUmVn YXJkcywKPiAgIEluZ21hcgo+Cj4gQnJ1Y2UgTG93ZWthbXAgd3JvdGU6Cj4gPiBJJ20gYXR0YWNo aW5nIGEgZmlyc3QgZHJhZnQgb2Ygc2xpZGVzIGZvciB0aGUgcmVwbGljYXRpb24gZGlzY3Vzc2lv bgo+ID4gb24gV2VkbmVzZGF5LiAgKEknbSBhbHNvIGluY2x1ZGluZyB0aGUgcmF3IHRleHQgYmVs b3csIHdoaWNoIGlzIGEKPiA+IGxpdHRsZSBiaXQgaGFyZCB0byByZWFkLikgIEkgaGF2ZSB0cmll ZCB0byBzdW1tYXJpemUgdGhlIGltcG9ydGFudAo+ID4gY29uY2VwdHMgYW5kIGlzc3VlcywgYW5k IGF0IHRoZSBlbmQgSSBwcm9wb3NlIGEgaGlnaC1sZXZlbCB2aWV3IG9mIGEKPiA+IHNvbHV0aW9u LCBhcyBJIHBlcmNlaXZlIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBlYXJsaWVyIGVtYWlsIHRocmVh ZHMuCj4gPgo+ID4gSSB3b3VsZCBhcHByZWNpYXRlIHNwZWNpZmljIGNvbW1lbnRzIG9uIHRoZSBz bGlkZXMsIG1pc3NpbmcgaW1wb3J0YW50Cj4gPiBpc3N1ZXMsIG9yIGp1c3QgZ2VuZXJhbCBjb252 ZXJzYXRpb24gb24gdGhlc2UgaXNzdWVzLgo+ID4KPiA+IEJydWNlCj4gPgo+ID4KPiA+Cj4gPiBS ZXBsaWNhdGlvbiBmb3IgUDJQU0lQCj4gPiBCcnVjZSBMb3dla2FtcAo+ID4gMTIvNS8yMDA3Cj4g PiAyCj4gPiBSZXBsaWNhdGlvbiB2cyBFcmFzdXJlIENvZGVzCj4gPiBUaGlzIHRhbGsgZGlzY3Vz c2VzICJyZXBsaWNhdGlvbi4iICBGb3IKPiA+IFAyUFNJUCwgd2hlcmUgdGhlIHByaW1hcnkgcmVz b3VyY2UgaXMKPiA+IGEgQW9SLT5VUkkgb3Igc2ltaWxhciBtYXBwaW5nLCB0aGlzIGlzCj4gPiB0 aGUgcmlnaHQgYXBwcm9hY2guICBGb3Igc3RvcmFnZSBvZgo+ID4gbGFyZ2VyIG9iamVjdHMsIG1l Y2hhbmlzbXMgc3VjaCBhcwo+ID4gZXJhc3VyZSBjb2RlcyBhcmUgbW9yZSBhcHByb3ByaWF0ZS4K PiA+IE1vc3Qgb2YgdGhlIHNhbWUgaXNzdWVzIG9mIHBsYWNlbWVudAo+ID4gYW5kIHJlc3BvbnNp YmlsaXR5IGFyZSBzdGlsbCBhcHBsaWNhYmxlCj4gPiB3aXRoIG9ubHkgc2xpZ2h0IG1vZGlmaWNh dGlvbnMuCj4gPiAzCj4gPiBUaGUgUXVlc3Rpb25zCj4gPiBXaGF0IHNob3VsZCByZXBsaWNhdGlv biBhY2hpZXZlPwo+ID4gV2hhdCBwZWVyIGlzIHJlc3BvbnNpYmxlIGZvciByZXBsaWNhdGlvbj8K PiA+IFdoYXQgbGF5ZXIgaXMgcmVzcG9uc2libGU/Cj4gPiBIb3cgbWFueSByZXBsaWNhcz8KPiA+ IFdoZXJlIHRvIHB1dCB0aGUgcmVwbGljYXM/Cj4gPiA0Cj4gPiBHb2FscyBvZiBSZXBsaWNhdGlv bgo+ID4gUGVyc2lzdGVuY2UKPiA+IOKAoiBEYXRhIHJldGFpbmVkIGFmdGVyIGNyYXNoIG9mIHJl c3BvbnNpYmxlIHBlZXIKPiA+IOKAoiAiUGVybWFuZW5jZSIgYWZ0ZXIgc3RvcmluZyBwZWVyIGxl YXZlcwo+ID4gU2VjdXJpdHkKPiA+IOKAoiBEb1MgYnkgcmVzcG9uc2libGUgcGVlcgo+ID4g4oCi IFJvdXRpbmcgYXR0YWNrcyBhbG9uZyBwYXRoIHRvIHJlc3BvbnNpYmxlIHBlZXIKPiA+IExvYWQg QmFsYW5jaW5nCj4gPiDigKIgUXVlcmllcyBmb3IgYSBwb3B1bGFyIHJlc291cmNlIGRpc3RyaWJ1 dGVkCj4gPiBiZXR3ZWVuIHJlcGxpY2FzCj4gPiA1Cj4gPiBQb3B1bGFyIFJlcGxpY2F0aW9uIFNj aGVtZXMKPiA+IE5laWdoYm9ycwo+ID4g4oCiIFBlcnNpc3RlbmNlIHdpdGggbG9zcyBvZiByZXNw b25zaWJsZSBwZWVyCj4gPiDigKIgREhULWRlcGVuZGVudCBkZWZpbml0aW9uCj4gPiDigKIgVnVs bmVyYWJsZSB0byByb3V0aW5nIGF0dGFja3MKPiA+IOKAoiBEZXBlbmRzIG9uIHJlc3BvbnNpYmxl IHBlZXIKPiA+IFJhbmRvbSByZXBsaWNhcwo+ID4g4oCiIEZpeGVkIG9mZnNldHMgb3IgdGV4dCBh ZGRpdGlvbiBiZWZvcmUgaGFzaGluZwo+ID4g4oCiIFBhdGhzIHRvIGRpZmZlcmVudCByZXBsaWNh cyBhcmUgaW5kZXBlbmRlbnQKPiA+IOKAoiBIYXJkZXIgdG8gcmVwbGFjZSBvbiBsb3NzIG9mIHJl c3BvbnNpYmxlIHBlZXIKPiA+IFF1ZXJ5LXBhdGgKPiA+IOKAoiBSZXBsaWNhcyBhZGRlZCBhbG9u ZyBwYXRoIHRvIHJlc3BvbnNpYmxlIHBlZXIKPiA+IOKAoiBHb29kIGZvciBsb2FkIGJhbGFuY2lu Zwo+ID4gNgo+ID4gV2hvIFJlcGxpY2F0ZXM/Cj4gPiBTdG9yaW5nIChvd25lcikgcGVlcgo+ID4g 4oCiIENhcmVzIHRoZSBtb3N0IGFib3V0IHRoZSBvdXRjb21lCj4gPiDigKIgU2hvdWxkIGJlYXIg d29yayByZXNwb25zaWJpbGl0eQo+ID4g4oCiIENhbid0IHJlZnJlc2ggYWZ0ZXIgbGVhdmluZwo+ ID4gUmVzcG9uc2libGUgcGVlcgo+ID4g4oCiICJSZXNwb25zaWJsZSIKPiA+IOKAoiBFYXNpZXN0 IHN1cHBvcnQgZm9yICJwZXJtYW5lbnQiIHJlc291cmNlcwo+ID4g4oCiIExvdyBvdmVyaGVhZCBm b3IgbmVpZ2hib3JzCj4gPiDigKIgSGlnaGVyIG92ZXJoZWFkIGZvciByYW5kb20gcmVwbGljYXMK PiA+IDcKPiA+IFdoYXQgTGF5ZXIgUmVwbGljYXRlcz8KPiA+IERIVAo+ID4g4oCiIEFwcHJvcHJp YXRlIHJlcGxpY2F0aW9uIHNjaGVtZSByZWxhdGVkIHRvIERIVAo+ID4gYWxnb3JpdGhtCj4gPiBB cHBsaWNhdGlvbgo+ID4g4oCiIEtub3dzIHJlcXVpcmVtZW50cwo+ID4g74KnUGVyc2lzdGVuY2UK PiA+IO+Cp1JlbGlhYmlsaXR5Cj4gPiDvgqdQb3B1bGFyaXR5Cj4gPiDigKIgS25vd3Mgd2hlbiBv d25lciBpcyBwcmVzZW50Cj4gPiDigKIgT25seSBsYXllciB0aGF0IGNhbiBnZW5lcmF0ZSBuZXcg c2lnbmF0dXJlcyAoaWYKPiA+IG5lZWRlZCkKPiA+IDgKPiA+IFBvc3NpYmxlIFNvbHV0aW9ucz8K PiA+IE5vIHNpbmdsZSBhcHByb2FjaCBzb2x2ZXMgYWxsIHByb2JsZW1zLgo+ID4gUHJvcG9zYWw6 IFdlIG5lZWQgYm90aAo+ID4g4oCiIERIVC1sZXZlbCByZXBsaWNhdGlvbiBhbHdheXMgYXBwcm9w cmlhdGUsIGNhbid0IGJlCj4gPiBkb25lIGJ5IGFwcGxpY2F0aW9uLWxheWVyLgo+ID4g4oCiIE9u bHkgYXBwbGljYXRpb24tbGF5ZXIga25vd3MgZW5vdWdoIGFib3V0Cj4gPiByZXF1aXJlbWVudHMg dG8ganVzdGlmeS9kZWZpbmUgZnVydGhlciByZXBsaWNhdGlvbi4KPiA+IOKAoiBSZXNwb25zaWJs ZSBwZWVyIG5lZWRzIHRvIG1ha2UgYXBwbGljYXRpb24tbGF5ZXIKPiA+IGRlY2lzaW9ucyBhYm91 dCBpdHMgcmVzb3VyY2VzLiAgTm90IGp1c3QgREhULWxldmVsLgo+ID4g4oCiIEludGVyYWN0aW9u IGJldHdlZW4gdGhlc2UgbGF5ZXJzIG1heSBiZSB1c2VmdWwgdG8KPiA+IGRldGVjdCBtYWxpY2lv dXMgcGVlcnMuCj4gPgo+ID4KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBQMlBTSVAgbWFpbGluZyBs aXN0Cj4gPiBQMlBTSVBAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3AycHNpcAo+Cj4gLS0KPiBEaXBsLi1JbmZvcm0uIEluZ21hciBCYXVtZ2FydAo+ IEluc3RpdHV0IGbDvHIgVGVsZW1hdGlrLCBVbml2ZXJzaXTDpHQgS2FybHNydWhlIChUSCkKPiBa aXJrZWwgMiwgNzYxMjggS2FybHNydWhlLCBHZXJtYW55Cj4gUGhvbmU6ICs0OSA3MjEgNjA4IDgy ODEsIEZheDogKzQ5IDcyMSA2MDggNjc4OQo+Cj4K --===============1777543773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1777543773==-- From p2psip-bounces@ietf.org Mon Dec 03 20:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMeE-0001vU-O2; Mon, 03 Dec 2007 20:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMeD-0001up-Qz for p2psip@ietf.org; Mon, 03 Dec 2007 20:32:29 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzMeB-0002uS-L8 for p2psip@ietf.org; Mon, 03 Dec 2007 20:32:29 -0500 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lB41WQHj001620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Dec 2007 20:32:26 -0500 (EST) Date: Mon, 3 Dec 2007 20:32:26 -0500 (EST) From: Salman Abdul Baset To: Ingmar Baumgart Subject: Re: [P2PSIP] 500+ Node Overlay using P2PP In-Reply-To: <47543FBE.9080608@tm.uka.de> Message-ID: References: <47543FBE.9080608@tm.uka.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1196731946=:2939" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-684387517-1196731946=:2939 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE The source code release is in the near-future plans. The 500 node network= =20 uses Kademlia. We have also run a 100 node Bamboo. regards, salman On Mon, 3 Dec 2007, Ingmar Baumgart wrote: > Nice work! Do you also intend to release the source code of your > implementation? > > Is the currently deployed overlay on PlanetLab based on Kademlia or Bambo= o? > > Regards, > Ingmar > > Salman Abdul Baset wrote: >> We have implemented Kademlia and Bamboo over P2PP and are currently >> running a 500+ node overlay on 160+ planet lab machines. The >> implementation uses the reliability model of P2PP and is compliant to >> P2PP-01 draft. We have overlayed the routing and resource tables of >> nodes on google map. The routing and resource tables of 160 live nodes >> can be viewed at: >> >> http://www1.cs.columbia.edu/~gg2265/kad3/ >> >> The display script is a bit slow and we are working to improve it. >> >> A rendering from an earlier run of 50 nodes can be found at: >> http://www1.cs.columbia.edu/~salman/p2pp/planet/ >> >> I plan to release a 'client' executable very soon which folks can use to >> insert key value pairs in the overlay and view the results immediately >> on nodes. >> >> Regards, >> Salman >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > --=20 > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 > ---559023410-684387517-1196731946=:2939 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ---559023410-684387517-1196731946=:2939-- From p2psip-bounces@ietf.org Mon Dec 03 22:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOCX-0001Ja-9g; Mon, 03 Dec 2007 22:12:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOCW-0001GX-C3 for p2psip@lists.ietf.org; Mon, 03 Dec 2007 22:12:00 -0500 Received: from wa-out-1112.google.com ([209.85.146.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOCW-0003qd-1I for p2psip@lists.ietf.org; Mon, 03 Dec 2007 22:12:00 -0500 Received: by wa-out-1112.google.com with SMTP id j4so5875893wah for ; Mon, 03 Dec 2007 19:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=7P55LGLK8uli8bkYhZhWVhjpjyrJtt8QOVUmIvKRXmU=; b=vxhGk4O3G78fyBSjPb069Fz7Ld0kRyLReDPuI6gZY0AFjupvqJMpsNHZduKCUxm2RiT6A+96mP01i/sTwHZycsBVcrgCoUypw+FHr/m62XAHPnMAw5xhjnZEz9+SIluo7dXjmETeuJYfJN35VuOppls81H6e1rX8wUq/ZyMA/OA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MeIaBkc6EtmhmCwyapgH9+YospMvCKiP6DMwudTjmjDxy8AOJZwoIWZaDmDxl65DgKGKbrCoKpLqk3XAPCP6SYcJf1ZvcDGjEo/9/GPPUD6UvQLv/u3mfDXbLRuslrBUsYcsL6o4wK6899bfGQ28AWQbk2CHEuLcOFGj9SeAA8Y= Received: by 10.114.37.1 with SMTP id k1mr179941wak.1196737919423; Mon, 03 Dec 2007 19:11:59 -0800 (PST) Received: by 10.114.209.13 with HTTP; Mon, 3 Dec 2007 19:11:59 -0800 (PST) Message-ID: <20d2bdfb0712031911k5ec4c8acudb784681dbf39d3a@mail.gmail.com> Date: Mon, 3 Dec 2007 19:11:59 -0800 From: "Bruce Lowekamp" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] Routing discussion slides for this week's session In-Reply-To: <47547EDB.6000300@tm.uka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <064301c835f6$39675780$f7168182@china.huawei.com> <47547EDB.6000300@tm.uka.de> X-Google-Sender-Auth: 9ae88f655213f0e6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12/3/07, Ingmar Baumgart wrote: > Spencer Dawkins wrote: > > David has graciously uploaded my slides to > > http://www3.ietf.org/proceedings/07dec/slides/p2psip-0.ppt. > > > > Please don't feel that you must wait until the face-to-face meeting to > > respond to this presentation passionately ;-) > > I would add at least two benefits of iterative routing: > > 1) Iterative routing makes routing more secure in case you have > malicious nodes in your overlay (by doing parallel lookups over disjoint > paths). > You're right, iterative makes security and fault diagnosis much easier. > 2) Some overlay protocols like Kademlia or Broose are designed to only > work with iterative routing (because these protocols maintain their > routing tables by learning form incoming lookup requests). > It's going to be tremendously painful to implement a dht for peers behind NATs that insists on being iterative. I would rather utilize a modified algorithm or just say that it's fine to have DHTs that don't work in all environments. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 22:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOJH-0002f3-5j; Mon, 03 Dec 2007 22:18:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOJF-0002eq-NW for p2psip@lists.ietf.org; Mon, 03 Dec 2007 22:18:57 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOJE-0004S0-73 for p2psip@lists.ietf.org; Mon, 03 Dec 2007 22:18:57 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzOJA-00037M-SP; Tue, 04 Dec 2007 04:18:55 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IzOJ6-0002ie-VI; Tue, 04 Dec 2007 04:18:52 +0100 Received: from wooky.tm.uka.de (dhcp-11fb.ietf70.org [130.129.17.251]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 331912FC075; Tue, 4 Dec 2007 04:18:48 +0100 (CET) Message-ID: <4754C70D.7010608@tm.uka.de> Date: Mon, 03 Dec 2007 19:18:37 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] Routing discussion slides for this week's session References: <064301c835f6$39675780$f7168182@china.huawei.com> <47547EDB.6000300@tm.uka.de> <20d2bdfb0712031911k5ec4c8acudb784681dbf39d3a@mail.gmail.com> In-Reply-To: <20d2bdfb0712031911k5ec4c8acudb784681dbf39d3a@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce Lowekamp wrote: > On 12/3/07, Ingmar Baumgart wrote: >> 2) Some overlay protocols like Kademlia or Broose are designed to only >> work with iterative routing (because these protocols maintain their >> routing tables by learning form incoming lookup requests). >> > > It's going to be tremendously painful to implement a dht for peers > behind NATs that insists on being iterative. I would rather utilize > a modified algorithm or just say that it's fine to have DHTs that > don't work in all environments. Well, Kademlia is the only widely deployed structured peer-to-peer overlay in the Internet today. The eMule Kad networks is based on Kademlia with currently over 1 Mio users and uses iterative routing. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 22:25:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOPh-0006pc-2t; Mon, 03 Dec 2007 22:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOPf-0006lW-IZ for p2psip@lists.ietf.org; Mon, 03 Dec 2007 22:25:35 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOPf-0004yF-AR for p2psip@lists.ietf.org; Mon, 03 Dec 2007 22:25:35 -0500 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lB43PTMN014467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Dec 2007 22:25:34 -0500 (EST) Date: Mon, 3 Dec 2007 22:25:29 -0500 (EST) From: Salman Abdul Baset To: Bruce Lowekamp Subject: Re: [P2PSIP] Routing discussion slides for this week's session In-Reply-To: <20d2bdfb0712031911k5ec4c8acudb784681dbf39d3a@mail.gmail.com> Message-ID: References: <064301c835f6$39675780$f7168182@china.huawei.com> <47547EDB.6000300@tm.uka.de> <20d2bdfb0712031911k5ec4c8acudb784681dbf39d3a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> 1) Iterative routing makes routing more secure in case you have >> malicious nodes in your overlay (by doing parallel lookups over disjoint >> paths). >> > > You're right, iterative makes security and fault diagnosis much easier. > >> 2) Some overlay protocols like Kademlia or Broose are designed to only >> work with iterative routing (because these protocols maintain their >> routing tables by learning form incoming lookup requests). >> > > It's going to be tremendously painful to implement a dht for peers > behind NATs that insists on being iterative. I would rather utilize > a modified algorithm or just say that it's fine to have DHTs that > don't work in all environments. It is likely that peers will publish their address candidates (host, server-reflexive, and relay) in the overlay. Peers using iterative routing can send parallel copies of the request to the host, server-reflexive, and relay address of the next hop. If the address candidates of the next hop are not available, then a CONNECT-like offer/exchange mechanism can be used. -s _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 03 22:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzORt-0005Pi-D1; Mon, 03 Dec 2007 22:27:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzORs-0005Ks-23 for p2psip@ietf.org; Mon, 03 Dec 2007 22:27:52 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzORq-0005AA-Fh for p2psip@ietf.org; Mon, 03 Dec 2007 22:27:52 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzORm-0004Bo-53; Tue, 04 Dec 2007 04:27:50 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IzORi-0000Z1-46; Tue, 04 Dec 2007 04:27:45 +0100 Received: from wooky.tm.uka.de (dhcp-11fb.ietf70.org [130.129.17.251]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 5C9C52FC075; Tue, 4 Dec 2007 04:27:41 +0100 (CET) Message-ID: <4754C92C.3000900@tm.uka.de> Date: Mon, 03 Dec 2007 19:27:40 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] replication for p2psip References: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> <4754547B.5070905@tm.uka.de> <20d2bdfb0712031721k15ab322r6aec387407500830@mail.gmail.com> In-Reply-To: <20d2bdfb0712031721k15ab322r6aec387407500830@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 3.0 (+++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce Lowekamp wrote: > On 12/3/07, Ingmar Baumgart wrote: >> - "Who Replicates?". There is a second alternative for replication by >> the responsible peer(s). I suppose the approach mentioned in your slides >> is that the responsible peers pushes the records to all replicating >> peers. The second alternative (as it is done in P2PNS) is that all >> replicating peers pull the records from all other peers. In this sense >> there is not a single responsible peer, but all neighbors are equally >> responsible. I think having a single responsible peer is a big security >> problem. > > I'm sorry, I didn't see this in the p2pns draft, but I may have read > too fast. Where is it? My understanding from your statement is that > you're having the peers storing each replica mutually refresh each > other to maintain persistence? You're right, I should probably fit > that in somehow. Every time a peer joins it retrieves all data records close to his nodeID by querying all his neighbors. To ensure consistency this can be repeated periodically (e.g. every hour). Unfortunately there is only a very short description on this in the current draft. It's in section 5.4.1: > Data records are replicated on several nodes, because a malicious > node may arbitrarily tamper with locally stored data records. The > replicas are stored on neighbor nodes close to the key as these nodes > can be efficiently discovered by a single KBR lookup. > A peer resolves a P2PName to nodeID mapping by querying all replicas > in parallel. Thereupon the peer makes a majority decision on all > received replies to determine the most plausible destination nodeID. > In order to handle churn every newly joined node first requests all > data records in his responsibility from his neighbor nodes and stores > them locally. >> - I don't understand what we gain by additional replication by the >> application layer. In P2PNS replication is done only by the DHT layer >> and I would be interested if there are any (especially security) issues >> with that. >> > > I think the key question is whether there is one replica scheme that > can be appropriate for all applications that the overlay will be > supporting. The requirements for, say, storage of voicemail until it > is retrieved are different than for storage of a user's current > location that the user can refresh itself on a regular interval. Do > we want to use the same replication strategy for both or do we need to > somehow support options? That's the question I'm trying to get at > with slide 7. Maybe I should be more explicit there. Thank you for this explanation. I didn't get this from the slides. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 02:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzSGf-0007aP-Rm; Tue, 04 Dec 2007 02:32:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzSGd-0007OS-W9 for p2psip@ietf.org; Tue, 04 Dec 2007 02:32:32 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzSGc-0003Ir-KA for p2psip@ietf.org; Tue, 04 Dec 2007 02:32:31 -0500 Received: from [172.17.119.251] ([24.85.64.125]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB47WEqw021928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Dec 2007 01:32:18 -0600 In-Reply-To: <47547762.9050007@ericsson.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com><20071127220309.C632733C28@delta.rtfm.com><4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com><20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> <474EA5DB.4010201@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE363@namail5.corp.adobe.com> <47547762.9050007@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) Date: Tue, 4 Dec 2007 01:32:03 -0600 To: Jani Hautakorpi (JO/LMF) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> ers and other network elements have to >> understand HIP? > > No they don't. There is no such functions in HIP which would > require HIP-aware routers (or other middleboxes). > > They do need to be at least HIP tolerant. I think my firewall drops protocol 253 into the bit-bucket. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 02:53:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzSaT-0004sI-PU; Tue, 04 Dec 2007 02:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzSaT-0004s4-1B for p2psip@ietf.org; Tue, 04 Dec 2007 02:53:01 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzSaR-0004HG-9x for p2psip@ietf.org; Tue, 04 Dec 2007 02:53:01 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00BVILWAIL@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 23:52:58 -0800 (PST) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00J43LW878@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 23:52:58 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.64.136]) by szxmc03-in.huawei.com (mshttpd); Tue, 04 Dec 2007 15:52:49 +0800 Date: Tue, 04 Dec 2007 15:52:49 +0800 From: jiangxingfeng 36340 Subject: Re: [P2PSIP] Routing discussion slides for this week's session To: Salman Abdul Baset Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > It is likely that peers will publish their address candidates > (host, > server-reflexive, and relay) in the overlay. Peers using iterative > routing > can send parallel copies of the request to the host, server- > reflexive, and > relay address of the next hop. If the address candidates of the > next > hop are not available, then a CONNECT-like offer/exchange > mechanism can be > used. > Does it mean that ICE procedure will be involved in the iterative routing mode? If it does, the latency will be unacceptable. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 02:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzScB-0005ZF-RH; Tue, 04 Dec 2007 02:54:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzScA-0005Z7-Uu for p2psip@ietf.org; Tue, 04 Dec 2007 02:54:46 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzScA-0004M3-Ny for p2psip@ietf.org; Tue, 04 Dec 2007 02:54:46 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00024LZAVH@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 23:54:46 -0800 (PST) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00J5ZLZ878@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 03 Dec 2007 23:54:46 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.64.136]) by szxmc03-in.huawei.com (mshttpd); Tue, 04 Dec 2007 15:54:37 +0800 Date: Tue, 04 Dec 2007 15:54:37 +0800 From: jiangxingfeng 36340 Subject: =?gb2312?B?u9i4tA==?=:Re: [P2PSIP] replication for p2psip In-reply-to: <4754547B.5070905@tm.uka.de> To: Ingmar Baumgart Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> <4754547B.5070905@tm.uka.de> X-Spam-Score: 2.5 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > - "Who Replicates?". There is a second alternative for replication by > the responsible peer(s). I suppose the approach mentioned in your > slidesis that the responsible peers pushes the records to all > replicatingpeers. The second alternative (as it is done in P2PNS) > is that all > replicating peers pull the records from all other peers. In this sense > there is not a single responsible peer, but all neighbors are equally > responsible. I think having a single responsible peer is a big > securityproblem. > the pull mode may work. But if the has been changed or deleted, how does the replicating peer learn it has changed? _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 03:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzTAP-0002XQ-Mz; Tue, 04 Dec 2007 03:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzTAO-0002W0-0F for p2psip@ietf.org; Tue, 04 Dec 2007 03:30:08 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzTAN-0006Bb-Lt for p2psip@ietf.org; Tue, 04 Dec 2007 03:30:07 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2885538rvb for ; Tue, 04 Dec 2007 00:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=RvZRzKcRemPbzfMY+5thyPEJ3KKNJLQRNOhy3JhnHg8=; b=hDLVy/XiQ1MriYZ/TbwLV5hbTrm/JLX0S9M+vmGJmS50G1HHGQfZ2yETwWNBlFXYLftraW2UNFJ28O3ipTl/7ahKA1Z+A866nvAv1UebEOa8ApTKdrbdJUFQJJ1/KFbXwv3qzvjwZIe5Ei4H9MPLqBpOppmvs/dkXDgMzjiTkZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=xwDxDdghOcWwTnhotaPXpvz12smyAQd0B0puBtCVWEc5SbXdUFqOVZ/j5yKo3gvkZhb/MW2RqxhE6IQ0QA0W3FdNxetj63XEOSZ6dEEwO+ZesOVTvaw7hS2JkeD+/8cS8y78Zq1H+DSgxbl3KJt+DManVvtuO8BPWxBJh8r7IZk= Received: by 10.142.115.10 with SMTP id n10mr38931wfc.1196757007053; Tue, 04 Dec 2007 00:30:07 -0800 (PST) Received: by 10.142.132.18 with HTTP; Tue, 4 Dec 2007 00:30:07 -0800 (PST) Message-ID: <20d2bdfb0712040030h2ca51aefyec54d44c53c366ee@mail.gmail.com> Date: Tue, 4 Dec 2007 00:30:07 -0800 From: "Bruce Lowekamp" To: "jiangxingfeng 36340" Subject: Re: [P2PSIP] Routing discussion slides for this week's session In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 8cb0743324e3e641 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12/3/07, jiangxingfeng 36340 wrote: > > > > > > It is likely that peers will publish their address candidates > > (host, > > server-reflexive, and relay) in the overlay. Peers using iterative > > routing > > can send parallel copies of the request to the host, server- > > reflexive, and > > relay address of the next hop. If the address candidates of the > > next > > hop are not available, then a CONNECT-like offer/exchange > > mechanism can be > > used. > > > Does it mean that ICE procedure will be involved in the iterative routing mode? If it does, the latency will be unacceptable. > As I understand it, the proposal in P2PP is to essentially have what would be the candidate addresses in ICE stored in the overlay, so that as soon as you learn about another peer, you can try to connect to them directly, without ICE. I'd be very interested in further work evaluating such ideas. We've thought about this some, and reload-01 explicitly supported listing multiple addresses for each peer, but there are a lot of tradeoffs in terms of additional protection needed for the messages and demultiplexing, hop-by-hop ACKs (which I think p2pp uses for normal communication), and additional latency if you don't simply try all options in parallel/wasted messages if you do. But, I do like avoiding the latency of ICE setup, so I think it's an option that needs to be looked at carefully. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 04:37:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzUD1-0002N6-6z; Tue, 04 Dec 2007 04:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzUCy-0002Jo-DB for p2psip@ietf.org; Tue, 04 Dec 2007 04:36:52 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzUCt-0001AP-Ii for p2psip@ietf.org; Tue, 04 Dec 2007 04:36:52 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00FT0QO0U0@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 17:36:00 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSI00JWSQNU6F@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 17:36:00 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSI00EPJQNTXQ@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 17:35:54 +0800 (CST) Date: Tue, 04 Dec 2007 17:35:52 +0800 From: Song Yongchao Subject: RE: [P2PSIP] replication for p2psip In-reply-to: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> To: 'Bruce Lowekamp' Message-id: <011f01c83659$10381800$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_serBVgaczumi4Uh5ySTw6g)" Thread-index: Acg13IT47zHufk1aSuiaa/i1Sp7XkgAea81Q X-Spam-Score: 3.0 (+++) X-Scan-Signature: a9d73e3f1baa85c3e49b6549a89b60d3 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_serBVgaczumi4Uh5ySTw6g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all The attachment is the draft slides for our suggested replication mechanism in DHT level by the responsible peer. It has the following benefits: 1) It can be adapted to all DHT algorithms, 2) It can achieve load balance by distributing the requests to replica nodes, 3) The maintenance of replicas is simple, 4) It can achieve the availability and persistence of resource objects. Best Regards! Song Yongchao > -----Original Message----- > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > Sent: Tuesday, December 04, 2007 2:44 AM > To: P2PSIP Mailing List > Subject: [P2PSIP] replication for p2psip > > I'm attaching a first draft of slides for the replication discussion > on Wednesday. (I'm also including the raw text below, which is a > little bit hard to read.) I have tried to summarize the important > concepts and issues, and at the end I propose a high-level view of a > solution, as I perceive the conclusion of the earlier email threads. > > I would appreciate specific comments on the slides, missing important > issues, or just general conversation on these issues. > > Bruce > > > > Replication for P2PSIP > Bruce Lowekamp > 12/5/2007 > 2 > Replication vs Erasure Codes > This talk discusses "replication." For > P2PSIP, where the primary resource is > a AoR->URI or similar mapping, this is > the right approach. For storage of > larger objects, mechanisms such as > erasure codes are more appropriate. > Most of the same issues of placement > and responsibility are still applicable > with only slight modifications. > 3 > The Questions > What should replication achieve? > What peer is responsible for replication? > What layer is responsible? > How many replicas? > Where to put the replicas? > 4 > Goals of Replication > Persistence > ? Data retained after crash of responsible peer > ? "Permanence" after storing peer leaves > Security > ? DoS by responsible peer > ? Routing attacks along path to responsible peer > Load Balancing > ? Queries for a popular resource distributed > between replicas > 5 > Popular Replication Schemes > Neighbors > ? Persistence with loss of responsible peer > ? DHT-dependent definition > ? Vulnerable to routing attacks > ? Depends on responsible peer > Random replicas > ? Fixed offsets or text addition before hashing > ? Paths to different replicas are independent > ? Harder to replace on loss of responsible peer > Query-path > ? Replicas added along path to responsible peer > ? Good for load balancing > 6 > Who Replicates? > Storing (owner) peer > ? Cares the most about the outcome > ? Should bear work responsibility > ? Can't refresh after leaving > Responsible peer > ? "Responsible" > ? Easiest support for "permanent" resources > ? Low overhead for neighbors > ? Higher overhead for random replicas > 7 > What Layer Replicates? > DHT > ? Appropriate replication scheme related to DHT > algorithm > Application > ? Knows requirements > ?Persistence > ?Reliability > ?Popularity > ? Knows when owner is present > ? Only layer that can generate new signatures (if > needed) > 8 > Possible Solutions? > No single approach solves all problems. > Proposal: We need both > ? DHT-level replication always appropriate, can't be > done by application-layer. > ? Only application-layer knows enough about > requirements to justify/define further replication. > ? Responsible peer needs to make application-layer > decisions about its resources. Not just DHT-level. > ? Interaction between these layers may be useful to > detect malicious peers. --Boundary_(ID_serBVgaczumi4Uh5ySTw6g) Content-type: application/vnd.ms-powerpoint; name="Responsible Peer Replication.ppt" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Responsible Peer Replication.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA9gAAAAAAAAAA EAAA+AAAAAEAAAD+////AAAAALsAAAD3AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A bh7w3tQAAMLheBVK+OmNe2gC/1+NM/P/iVBORw0KGgoAAAANSUhEUgAAAiwAAAH1CAMAAADicFWh AAADAFBMVEUDAQFUe6XbztfJvbqPIhfS2+jKuajNxsmttcaprLfd1tpFSlSbpbLGtJtuRi5LBwFx cG25ydvjTpvLvcdDWXJIY3qKSDPZi28yY4wrWoe5vceoqarOcWAtAgFrJhGou9Wrmo+0ZlTp7/br 6eyRinKYmZi8rZUrLCuttbt6hJhTIQ2Urcze1s2WUERyBgO8tauwjnaEnL05UGd4NCLn1s6oWE3H ztm4ralrlLV6nMY5apSMdnDe5+6HiIZyUUSqppqWm6m9tZdTaovKlIqfIFJNNCnO1t61dWz57e1r c4ubtczNxryUaVW0Zy5Ca5WYlofcVyqMlKaEi5rk3OfQF3RoZFwtNkHrqpP0tKrXvLapUi4tIhGE jKXWvaxja4O4pYq8xsuLlJd5fXJle5jozsvx592XiocYIiutxtf8ybh3e4JSc4xze5QQExg6QDPW xq2UQBKom5/ziDdiNkJKe6Xv9/fUk6RzlK2zpWe4xqrpmYGLlIu/JR6/SW2qoIGmUhTLqqGctda2 rbYUHg3thr6ajVf57/drV11zjKyKYjubpaKwgF3829bOyZJyFh+PU2QqFRZHFB7/9+tXXVybnLOc hpXOxqzZqaD9xNDAtoaAgTmoslLR1smMpcZahK1rjK17nL2EpcZzlLVjhK1ahKVrjLVjjK1zlL1K c5yEnMZKa4zn1tbezsZ7lL1Sc5x7pcZznL3n3t7ezs5jjLVSc5RSe5y1tb5ae5zWxrVCc5z///9S hKXVzs7Wxr1jhKVKa4RKY4Tn3tbWzsZKe5zezr3AtbXn1t7exr3WxsbVxtDv3t+1tbVCc5T39/fe xrWMpc69vb3Wzr339/+Mrc61vb1ac5ONrcX3//97nLW/tb57lLS9vbRae5RajK1ShK3v3tXexcZr hKRKc5Tv1tRtjKP/9/dac5zezrX/9/9je6VjjKXexs5rhK2tta1zjLX///fv1t5Kc4zTzrXQrbOe rcNznLVrlK3l5969znPnztZSa5T3//dSe5SetNHJ0t7///9QiUg0AAABAHRSTlP///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////8AU/cHJQAAAAFiS0dE/6UH8sUAAAAMY21QUEpDbXAwNzEyAAAAA0gA c7wAANBXSURBVHhe7f0LeNXlme6PB0KIIRGCKNgECCSEcJSTQCoJQRGQg1BQaBXlZAuUmlQGaff2 VH/S1gK/jWGn1V9nT0gISUA5KGjAOkBbpjoo0ovdIkVor5npnul/7K7O/7qq9j+/fQn/+36e5/0e VtZKVg4EYte7krVWVg6QtT65n/t53ud936TLiZF4BuJ8BpLi/LrElyWegcsJWBIQxP0MJGCJ+6lK fGEClgQDcT8DCVjifqoSX5iAJcFA3M9AApa4n6rEFyZgSTAQ9zOQgCXupyrxhQlYEgzE/QwkYIn7 qUp8YQKWBANxPwMJWJp8qn5TNCnrcNqwrEmpM4uK8jaejvt5/Vx+YQKWJl7W3NSMjLTrrht2XQZG GscPh2WtSLkn93OJQvO/VAKWmM/RxiyAAlSGXZd23WFcrsuSD/HAsLTrVlxKues3zT+9n6+vSMAS 4/V8Y1JaGrAgKuADpGQ88EDGdWcPgxwSg89dl3Z40sy8v6bIlIAlBiwpIisCBpXlh4tmL1s2++GF jEpKjxCTlvHAtKweuW98vhQk1m+TgCXGM5MqkpKGy7DrstIeACoyHv4h4hFjkXyC5GQsXPTwwxlZ Kbmff41JwBIDFmGBV8OuO5w23FDBzexpoikeL2Anbdqih2c//PDwhRkrenyukUnAEh2W0z8UHCTg BFkBLRmqLPIpecu6DvIy/GEdwx9IWwEn87kMTAlYosOSm2HqMczXFagHo9HDkk27SCTMHM5K++Gi 4TLAy+zZQCZjRcrnzvwmYIkOSw8QobFm2AMag2YPn/bDjGkLH1627IFhhwORCF9F85KVtlBpMWRm Pzx7+MKsjZ8r55uAJfrLucJIQR5krCxE7pOWdl3G8DuWTUMFBhSJrfG97uEfDn84wAtFZvbDWZ8n 25uAJSosb2RlKAWHP16ksCxMS9MibtrDyxapx/VsLu9IKQaBKswL8Jn0+RGXBCxRX8vTljQPy8pA 3Fk2e9nwDLLyMd6HLYRryXL+1oOGKvPD4ciiG/GysOjzgksClqiv5EbUWLSSMs0TFtACVvA2e3aG xiErtkgwggilTRv+wAMPLFq0CHoSYibjc2JdErBEhSUvQ/3I4etob2cve1gx0auFsxdSWVwcAjeC TlbG8OEPLMKFxIAZyYwYlh4evujzYV0SsESFpeiHFoesxrJIQVFkMoYvRCnOKryiQPKRwEJWCIwi Q5XRdHrR58G6JGCJBssbk6zylgU7a/aWfkWVJWPRQotRAXEBMBlKiZBCaSEvHjEPfw6sSwKWqLCs 4KwyJAMJjtRYfqi6Qln5OC1t0cIsq9+aXVED80Pw4QkLUfGJITMPp3V265KAJRosp7OgLIwuh6cp LC4Cibx8TGWROoul0GZ04W89WhQUh47cWzj8cCdPixKwRIXlMA0uxUWTIfpbNSxyGb7QKriclFar S6VhMmR4mGvxopJ8PPxSApZO/gxE++9v1PotMhxVFsLysdnbtLRpD0s2pBdNsEVbFjZSFudhFKGH 8zr5U5VQlmgvYC4J0DKL8yxmWUDMdYvQvqJfYEjJlx5OWyhMBENRhLIkPEsn/2tpsswC06pdTyj2 y5CMaLbOOwdTIZkbiFQWtbhmc0lRZ3+qEsoS7RVETU7me9KQOt9BXFDt12QIudA01OQO+8HHXC7K LAFLa/ISVpZpCVg6+zMQ3bN42qHziLOnEROZG0p7GO1P4lc0Upm9YZlF0uXQVVBZFg3r7E9VQlmi 1ll00plvC3VuCBYXFRZc4QGr34Y9C5IhRpoIXrwaHT/X6Yu4CViil/tVPDjhgxKuBqLrxLVMWzbc GVtLgsy9EJZIXEIl3eEpCWXp7M9A1P//v7HeL1UUJy3LHl44LSNj2gPWgysByJJny4tcTc6XF58V 3nu4sydDia1NY7C+ERZWqrRowRWLS+MiPbhYC6KQWDYkC0ZQzT2MZMgV+DUayZvd4N7wf+/sf1eJ MBT9FXyjCG1OYlpc9qzALNNKf6AUp4U5vLvMWZTFy5j9yaJOnwwllCXWX/sbefQoAoY0y5m4TFPf q7yYeeENyyyh1Eclxb3zo7TOLiwJWGK/grlY7SzygkYVDUSzH8jIOhxKmC1vBi4ss2jbk737UchS oqwELJ3+GWjiF9g4E+oC0ci6LuMBLAWaliEbKbDCYgUWz7wAqYxFmBriTLPDxXMrNgvQ6ZOhhLI0 DfsbKbIzy+GsrMPXZWVJF4uucXblOIlE4oQX2pJE6+9nl5yHjrTMdfZpxMsJWJpRxtMrJqH1YCGa n7hDi7kViI0QI9fYhAPVl4UIPrOXzZahIUsG10BzSesDD0yb1vm3c+ms2dDpot69e18quuKrLHKz Jk3CzCFf8IU/xIwze7gxIDRMl3HJmDZt4cIH+LZI+TBYPE+Mel7K6c/H2udOBwsoyTn37SN79hx4 bQ/GgT1V3678OKf3pCvETe6KSZMy/ACz6IGFYAN84Br2ZPhwdsDZeCAWLBmfF1/X6WDZVVt7vPY4 3kDKa2DlAG9eE3CuBDd5WZdS0zxYot3BDj8gByOWsvys8+fMRntng6Voxy43jtfuIDe1xxtEYkhO kJtxH89pB70BLAFliU7NA03DsiwBy1WS1iKgclze5Zro8G5tbZfaI8ePHAcve14TueFwekNuercu ThXBs/hhqElYYoahTt+a4F7rzqYsvckIQdmxawdQASZ2Tx7BY7W1R4SbDwQV1RtncBCnjJu499q5 5/Cl1OZgaSYMLev81bhOGoZ6e6IiikJc9FJ7HPAcrxV4du1AhNpRC24+6HIEQ7ghNiI1UB7xN3Fx kxJ/GIqpLAlYrlIYmqOOBVyIjuAO+RBGSAvvQVzkBp8BMnw/ziDlsFFnQ27kKshNlL1UUpg6N2lw H364Oc+y4io9V+3+z3a2MDTHwpDKiSgLyQEloip64QNyjw4YqFBm8IGoDbWG3DSoylBnAtwc//Z5 9TeOm0mpk1Jl25UmRnOwdPoOuc7qWSo1DDHU7AIg5ELhUGb0IqCIxuA+hIZfxFsM4EJoBJwPBJsu qNl49kYMsgqOcoPpoBXNKYt5luGx6iwJWNpd4+L7gZWiLBKGanELUCwcUULcBaQQGMQggsJ7fEAp Enw0696BR0CNkEVouhxBEm6Cc0CMjdVvGo689t57Dz30UAx1UWV5ICYsM+P71a79r+psYaja/KwI jHoWZQQBKaAs1BLKiSoMMRFhwRU/AUoMJ6qP2GKCIz9PuWk4wvxbEym7KEYHDvzht7+NwMbCUAKW aw3383hB1c2qstDo+pQEzAohIhQEhZQ4ZSElBIchSj+rRkfviCOWEEduuhz5oOFIQ4MlU+RGPI5V cYybh5zBjQnLFZ/A6qgXqbMpS41W4sTdQhHkNQ1oCgCgTmgaTUIoLeDAUxbiJfFJkiTRJc8W4wfJ z5JrYZHUcNQep7tpaNDYJNNSuOuKOLh35Mjxhx5676HoE4n3dNSLeaX/nU4Hi5ZvoQEUF4YfCUeB iwQazYCc3xUqJCHSMKTRSJIlSbbt6ySPsiofYaQh4iNqk2xQb7o0NCCZ0uKN0xrlh3Hqtff+3/fe ey8w69z5G1k6aVGuyiKQpESEJsSJyAhfcFENJUbJkdBjjygnGns04VZaJOuWqMYfLKgw4HmTCzbT 4HEjeTjlRsHhLXmxQg6VB74Y2KR8Xg6z6mzKUuUKLFbrD9EidTh6FPW0mj2bQ5FMyAmKMRIqzDDu aEySzJxFHJMU78ZJTP2u+l1806v6en4fqn7ibli3UWS04scizoE9R7797Y/PreidUtSpuelssNTj heTLjldT0+eAMuCVZrgRu0ItoaqIiLhsSJVFhCXkVlRlxLEw7KiyEBVVFXfjRSLDJMgM7vMN8DCd UndDTyMFP2/wrnCztlNy09lgMW/LSGPFFtECF1UssLDmJgZXK3HEx7gR8+KnPwGvI9iRNw1wYlac lTbbYtVj6InIilMWfsyHDBcgU19fVQ8NxFy4hqlA+q2plAauhm9/+9zHnYibTgeLagllRYRELy6n EceiabFUaqXKAgJYRpEwJK1TYnQjM26dNqBLkRyLvtnzKFYI1I+NE6HDcPFpUXWpr/+TI6a+Ctgg Tjm9kQyKmZTObGo2rtxQb2Ze03Gq08FiqVBAVhwueEFk1lDyYq3yW41f6yxqd9nFIAFM1Mgpi1gd ESjjxfmWCGC8AOSExZhRZcEFYFQRFVxTXfSqCqOu6lXegJvjkoVL9uQZG8vJBZwDqjczi665LKrT waK+QjMXDxNnZ0VixNeaUTFx0eqc2hXxK2pkPWkyu+JcrVZx/CxIPwqqiqFBj0KtcSFIA5Aqy58I jPDh3hw1AIeXeinfIEy5Bgq1Ni4jlzyc3ORcM9x0NlhIihTMoA0hZGh8dc5HyPHoIB4afdTBMM4I TcGLxCopsegkgpVXnEfxLQuEIeBXTE+8KKTWRZTFKQruCC1gQ+SlTq7tXp0M4eY4em+keKMhSmt/ AXtDbtiYjrPIr3TpLfbP72ywMFWRUOK92PrKS14c6IByhBAQxcW+RzyLX7Z1fTC0s5qVS6eMpc2+ WfF0RX2KWVxTFKGFA5Qg8uADF39IiKcsEodUVdyFd+S+G/X1x3dhNrwBE5lQHE2nNGB50+EH9ig3 HbAQJoKbzgaLTDbTl2jxza+ouZxY0p9IVBxcOl/Ei1di0SKuFOKkIizxxotDek/epbTi6iuOFyFD P/iToCLKgmt8QIURVKgkMlRYeCVvSkngHj78CA8Ughy8V4EbzcKtVSugN25Bw4UOlZlOBkuRZEKB 9ibNm73aCkVDiiY6I6TJs6bLGp9ck5QmVVrfZ0RjFHNgSAuesy2WI//RsHHMKDqeV/F9S1BTfFnx eDFGfFQoLI6burpPBZPCusKP8GhNXWFhYU1hTU1VlZRvyI2Sg1ssh/nT8eMNCVhiPwNFfFH5ynri oFHIpoJcuVYTH63eGiJia/0MKJAICTMMQhQtTh+aVQlU5LwKfyBXltKtpyxgxDRFtYWByE+F/Phj mhIIQ8KKMy+4/1Fh3Ue4+qiwpq6m8KMaXASYj2o4PiI3QEUGYtWRBCyxn4HeOomj14EYpB9KBUUv rinBMh/VnkC+7CdCnCiUmCbMhKq1LgIddyUVjUIuTdYsyPuICbPly4w/mvuEAlDYqzir4schKAou VXLtaCEpAMXDpaamDqzsASm81CZgaQIWZSToVzQVJgueVbHuBNEVlwNp4VatrZcIScTSgq2gYrOG nm2xNMgr1loZzje5VlxRSyuKooIixRXLiBw0QcfiGRZaFs2IBBN8AEo+qvsB3okL7gsqcu3UhVHI lCUBSxN/LTmavaiKyEvtkhzXguDURSOOlv9NhZSyMG2SNJuoaJFfnYs3+KFVav2pQ8/VmlexqopW WLQMZ7U4yZq9jNmwiJIMQUqAC9j49KPCKqgJoxDfPoKm1EkEMlTgYGhaGlRbqhLKEvsZmONkQWOQ yIZmxZCRb6xbtignZ86cC1VqV3QyUa99ttQAkxlNiyz5kQqL48Qe1Q99VDQb8tMiLw4h/YGagBMp svig+IlQqMASyIDEr8g78iCOj+BrPyr8AYwL6aC4+JgoNFVsmjHbUp+AJfYzcM7JiZXnrXdF26/v SE+/ZKP3is/mVI67UONNGgZ48eOYumTGNNWTsLP1E6KAsigqXslWS/xSZfEdbSAG8a6lO17G7NVW 5BE/E6qqqaqp+zZY+RTvNYWUGbUrUJcgMfWaDsHeJpSlyb+VSr/uKori0mOZPrwp/UYHi3c7aUXO nI8rq2uqJGmWGospi9fgpJSIuzVeQmmzCz7OqPgps1eL0/pKcC7IN7fBIku4IOclzZ66MGmmpgge En4Ul/Co17lI0nLg2wllif0MVOt0kNeQIh9JwIGLuSm94tLMlJkzZzZChg9AbD6rHFdTo/bWYpDB I8mQTiL4b0rPH0OBSPNlP2OGqsjFsuQIV4uSrYs4zraEeLEARGtLzwI6mDgTFFz5UaguDMwuLelK 7lyTgCX2M3DeK6ZpAuTsrcwP3pR+06WU3B5vv921BweoiYqNJzZ+shwOQRHdTgHPYvXaQBTSMj9p UW+rkiLXQEXngxwyvlUxo+JKLFQTfagQmMDiStTRKMT7AXeLu8etP4bKcj4BS+xnoMaV6UVR1Niq zcXbTenLLqXkvZ36NnC51LWrIsOREkNueq+YM6eyEmJjJdtwIKI1sZlmZ1SCoiIKw44EURZeN8qX XbIst0GNCegLHApk5QeSCcmlSk2KQBItCgEWmWWEyW1IwNLUH0uNeRbNnW1yWY1L7fEbAUtR3tt9 QAtQASzyJnfeeqsHLinKTeMo5YuN0xgLR6TFJoTMs7jJIItGWlgxURGT65RFpg09ZQkUVlzw0cJt Fdwsk2aZE0LmLFFI6irmb1nDDZmWWmsPp8Mdl1CW2M9AVdCzSB1ORUXEpYKw3NMntc/bb09SXFRc 7J5x00MenNkjutqI2Iw7j+VJnlcJlm29Gj9ti9TgnLJYCDJWbMLQJCUoJP48swYhqdh+VAVMWFUB KkIL7AurK43SZlJTS2UR09JwoDIBS+xnAA1DUn0TW0uni95JTCQTlR2148evAywr+qQyEBktAYkh NSBFKdLH38JHk7qmQG5ip1FOWYQeq+6zs0nuWlEFyEghTnSFybJlQxp9PNPiQpEPDGIQEQEhyIGY BjEEiaH13iKToZojumOI5M4JZWnir0W7CSShISYypczivvRnp6cTFrDCQDQphMtbIEUkRmhRsekB K4wveisvL++etxCnqDfRgpQnNl4iJNmQOBXTF8mGPG/ryYq528iMWaOPXYGRuk8/EmaktCKKIpOI jSixB7pI76UW5uYklCX2MyAN1a7JVlBhV5xGotrx6YsASxZQScUgCYhGl/yA5DkY1RdmTW/dk3cQ nJgX5s1bB+/pcU/0VIrOZiRKfXXqbK3bSaip/5M3FQRUqC1BFYnW8lQFRKApn8oUM4NOFZ0K2xJw pRNBjSosSksXa1KgtCRgaVJZrKtW4o4uXLbpwh0fpAOWvB7vw7SAFb4LMH5Egs81AyOo9OhxD4Y8 1KPHf/bY2/U/e/wn3tXoMEDFzsClQFx5vkY646TV1p8K8kNQMFX2S7WuK45mBW8gBfFHqvyYUPZc is0HRVMXWcom2dCBPdcllCX2MyCoWFWOrsX1OFFZjoxPX3gp7573+5xJ7dOHrFBgHC5OXxhtiAq4 QezRcNQVkIAWvv+nRSg+6NwNPskghuvGhRtNoyA2QkudRiI3c+jdc3EoWF5hcxPKcIUo8LvqPh2u WtsYmqLo6DJrLcvlJGCJ/QxIxV6S5lC/k9iXI+mEpUefPiv6nAEtwguBEV58C4MX/u3Urm/dc4+Z XD9J8nPtQ3jwrZAXJl8ETrxPtHpf77XXidh4HSwiHOFeJ4FGrzDQFVcHXJzBZWHFYRKlyO9rDJTl 927iOQFLE38tbOEXTrTtQNmxVqf3xqdnXMrtAc9Cj6vD5MUcDF7xHl37pB7NXzZp4bpTrgrjUqNA muSlSxAgu+9lV7A6YnYYxLp2nQlwwplU795wNufGnQ+Ubr2WBG/W8NO6QtThICKSBuGdeoLQA1fb rLLoklh1uL0TyhL7GdCVhFJgASLSmKA5NN7fSycsXc9AVlZQVEiMZEYkRqzL2326rj+74ugbR5dl LLppcXb2Mz0O7vVdTCNYqC9iXCRWUVv4Rj+jCB19u+tRj7QomVTvtZ/NOQex8QtymgWhYUXvSN2W 5X2ZCZLSPu67ESsW6co0mUtMwNLUHwsjkMwcqsL4+RA+/kb6+LRLuUezUlc4VVGX20dCUWpq1z5z v/arimk5szMvZg/LPVhx40Pjl2W/n0pL0lhUFBQAgff/FEgMFA1OxERBITG4xw967L3nnoNuWioo N5JGnRtXzapK3ac2CySG5QesraAcpz0JfvdkU6ZFNmZQz7KnY7er61zd/UWyklBExTridPmYFFrQ zvLxzNyjEJYzfc6s6LPijKZFFpJSU2evHJZxNHth72GZFRnr8i9Nq7gue13mwxWL5qYSgEMmEqDk EC5dDx3SwHPo6IkT/BRDDx3xUUjU0aNvgxF8Hpg4bVFeWOcjZ1o5fjsl0hMzjWL2TUw4eVhYyASa ukK7ElaW6HWW3TW2uaY0KXTs6WidDRZrR6BV0Vo/pUY3Rr5jfHrWzLxJZ7JICwdquRKH8H44NW/j ygc+y8jckpGWd3bZwn+dnbll+LTUhbMzFmWuG56Zn/qfee/sffuEiQZoIRO4OXT0EEh6u+s9bx0l UXyMpFBPwAyufFZMh3q8tbfHoUP7Dh3qupeP7O2xF5HOJsEDagNncx3EZpx5FrLSeH45Apfd+rFk ztbTkoAldhzqbdtPipi4tkoaGN7/aXp6VkrRqexTZ86ekQF1UZfbZ8XbR3vkpV43KXddeuXD6/LX LTp79qZpGTetWzl8Zdq6G4ffWDY7f3V26sF3uh6CswEKRw/x7SQTbLzgqX2yJ0OmKDhHgQdlRaRF gpEXrCxuiazsVXXaS8WiSAEduRetdYJpFLNvFm69doRYYYi82BJF6dnu2L2BOpey9NZpIdsQQZXF 5pxrj/8sffyKlINbHs/PX5/9zGHlJevMGVgYCM3bfZAI9cibtGzOx7MrHlg3bdjKRVkrK4Y/VDH8 8WUPb1lWsSy9Ysvkkj6AAAN++ND/fvt/93jr7fefeWbL6lWrMldNKV7/Zp+jxIVemV+Da9JCtAKx SAwMQxAJGbUXsnLoED6kPqk14s/wmidChZveK3JyRo4ch/6spocuUNQtXxKwxFaWHDUr0suicuIt ed9V+7P09N4pd42a+2Z2PkZ22ikCo9KCG5hcVm2xvfqw2RkLZy9btGz4lsxF05ZVrFuWvrJ49vB1 6WXpz2bvOymFPIaet9/Hz1ldvGrVquLix1cWZ65atTo7+eShvdAMCou+4cvkAwxxPXinlQEQPXqM Ojr3hJBiw5eeUV1HUWpkeDHKz8BjswJh2V3j1+QaDkQ5beAKJtOdS1nmsINWvYpOB+kkolZebkK/ dspdtx4aNepkcnZJ/sr87FPvn2EkEu+i1EBeuk7CKaor04f/a8Xs4RXrHr9p2aIbF2dWFJ8qXvLs +rkILm+BlVSAsnp1cfGQ4uLi1ZCqLVvyHwc2meDlzROs5jITp7zw4mihIZbciNEKD3dF+nXICQoj ER4fJdoi05mjuvbgR6I2GODqaGrqpKOXLk2K5Wz18To/G9pz4AqSEeVHdy5YzmkIcq3abE9waw13 oVFuPGDZe2jvrXv33jrq5JuT8xfkb8mmvgguZl8gMAe7rjj8w4z8zPGLbqpYV7wuo7gs/UenTp5Z 30dzGEhLn/WrV68aAk4Aykq5bMGleN2qzMwhq0veP9G1B+MQJMj8S4AYhiE3jr4NHgQTGOWj+9QK eXmXYIJ4JSYJtBw9mprM0JnalLLsrqnz9lXARGICltjPAJv7XbuTqosuPtTm/vEVaJTbi9eFZuHW vaP2ISKVgJdnYHXpctXsUl+63nOwK86Bz8hf9mzmj86k/mjhJEw033MPQDnZJzk5eW7q3Itjshc8 Xvy40bISgWglYhvkJTMT+rL+4gm+0ql0NyIylk8zGr1NJHhHyi+gg7mRPAYcMEZ1Velh0OLn1U4f PXSCWf7cM2cuNgELoxCWDb2mm40daOjYpc6d7Fzn8yyxNFIW2wK5AitBiu4apcYS77gc2geBKUEY yR4m+uJwoYeBW+gzLbNifY/USSiOIGjg7zr5zTff7A5akpNPnkx9H+bnccQhcPL4ysdxj+TkMxrB 7z4+ORmhRLywSIyGI7xTbhigSINSQ0pOnAALJ0+komZzwns48Gl8EVBJ7jM39czFFbHCEFOh/TVY CeK19ydgaUJaq7W6r55F21jU5bIJV1twJU8lMKBm1KhbMQ4dSx5Tsh7AMCAFx9Gj99zz9uEznJw+ SUyScbnIOxzgZd/R5DdLFgCX4uKVAIa3jz++Mh+PUF+K15ckzz15NHWuRiO+2kKJZEp2Rz5MxWdO njxx8ujJ1JOpJ1JNYIwjfp98m3536ty5cxsrixVYdkNXanbvsj29KS0du9S5kylLjU0cSk2OixCl 3GLrnQWWrxGRvaOACcwL7MutNDC3IiKNmbw+vyTtFKcZxcJYnoSXiaBMnqyE4P2i0cKbuakn+lws QTwSTqguuMEVWFm8OLO4hC15qW+DAsmhpFzMj/X1lwFSqBnAhcTolBUf8T7Hz+pXACzoyqm0M1GU RTjBuLC7ZtfvbQ8xrHU+nvAssZ+BjzQFos3VFSBadtHp53RRFtROGYCgKbg9dAjJ0SHKy61fHQWB QUgq2XKYFmYF02nWd2FQUufCqLw55s0xY8AH392YzIcQkyZDX1YVrwMl61aty0RStKp4df76ksln Ut/G64/X+ORRVPDAjAGTegJKQSIMDvwDffrMRYyZS2a8gW/E6Hqwx1yUgs6cyS7OXJy5aOXwjFgG dzdQubBblg3ZauddCViaaO4XZfFCkJkV2SdhR216+myFBeICYg6hIoaBcASdUWBu3Qdg1m/Zsv4U cg5OBDAozdUJpLnAZczkyd3HYJCRMd2JzJjJb04ek5yc2ufUetTmFgMTcDIIOjSXiTJfecSWkyeP IsgEKHDykYqow4F/RfKcZN4RZo6ieVM/M6x43bqVW/Jx+Py6ijVLlqTftGxlJCyUFVx2o8i7v2a3 NPdr81NDx65e7WRhqF56E7Qjwe3jJAeEUGXGo18772v7AAfVpAflBayQlr3UGQSkW/f+r1tvPfZm yfr1KNqdQgWfykJkKC7AJTm5++TJk8dMBi98xxUvQ/HYZHzZqfUL8kuACcUEMsJvFFRIHa7FtSh4 /pBPQrjOALxTZ2ia4EmgMdn5xcVb0pCXF2emLykoq6hYljk7c1nFjelr1qQvDMFifoWzAbvByn5v QSKr/QlYmm7BNbfiJhF1AznuhoAW3OGXiv6iZXYKS9dRe0EMEiMWXsDKKAADamBh9j0/pmQQc6TD Z5Ln4qXDq9nnJCQGN3At0BdvEBRGJ5CRCknYh3SZsYT5NWhhdAFpJ/HNxIbIIKjJ7OVcuU7m1yT3 uYg8i1r29qSuR2d27XPx4qn8iiUFSxZXZK5bl1mRnr5kTWn67HXrhi9atK6iYskyH5aAsyUpQguO dNTGJyxI7Nilzp1MWbituSxr1h5/bcjV/cJ2NaSPX3Qp9yCUReMPEBFwUHChsoATvVZgRs1FhrQA vuMUs+S5J5MFFYKTDGszeWhJyeQSgILsCC+4iANuT0IWgAO+UONJn7mgi58WjWJ8oZLgYaoVKUkG JdreefTtSSzg4d6KM6dQxFm5rqKgdMmy4sXLihcVV1SULVm2cNq0lQsz0lauW9R4shm6cgGoiGc5 Yu237Gfp2KXOnQ0Wly1bj7/tECa0oAV35cy8g/toWKTKAnWhW1G7S9MCXJQVUvNP/3TrPqbUgxBZ 8ILOBQl47YUZuF1Jj/ARIeEDRMVuaDkAlzzCL+a3gSFqi7pYIYs4iTHCgO0lPTq1efHU4YunkHOd 2gJNKUu/EZFo2pZF6xbfhDLR7OGLhq9bNC0MizoWyApQwfsFKottudGQgKWJMOQX+nU9om64Iptt 70AL7sKZuQfpbgEKLS5BEaNLaUFi5ISFDobJ9aFRX913rDtEJBu8QCjwurN8CwioLxCZuX3OKCGC itEiH8lXekMAs0dpgvB9UBRdXYBS2xk4FsY2hLOLb5568xTHmA8//HALJAVBqAJJFsJRetmSJWXp FcvW+bC4hBmoSNYsgaiLBCDdy6djV692MmWRcpxMJXKzJr8ix/1VvpGePi0l76DU4nocQqShshAU tbqqJyosAGXUqH3Mk5hTswYDYCRJDgy83KGP8IGgY4/KfTARQIaJjqZYyRdPnXnzFJIoUgPHAlhO wS+fMlIAS1r25A+zs7dMyyxYAn2pyMxctnhZRcGaJenL1p0XZTG7ImLCD/arvd3PlSCygQKzoQQs TSmLtfLL0R5ucxbbVBAtuBkpuXslDJENOJNRPdioJv7FyPCdy6GvjvoqaNm3bx9CEnJqZMrJ3d/s 3p0mxYZ39+KbgOJ9sPL+xfWPl8jD1J7kk6MO8eZ9PHJRQXpfELqIcCPVvYt4+P1k3EFWxQFKnvlw zOQPJ2d/CFQAy5YtK1elFwAWZkPr1iEfenhhoM4iLQk0K9QWZWU/th60PcIaDpxL1Fmaau6X8GOb svhxiFt/oQU3A5POUuZH8sM8iLpi1Ra9K1JC5yLGBVdfxRfvG/VVgrPv2LFjUpsLKAxebkoD5gCg D6zvJi9YvEC05cybc+eembxg9fruVsW7CDBYmQEmIOTimYuwJafoTgjNmMnZJbhkZ0+enI0LZCUt +8M0fMx5q8cz1y17GPMJC6d9/HFafsawc+pZ/Jz5wm5xKyTlwu5PdPNB7uRzoKFjV692tjAkxta2 ewqwwoQILbhpKbmKCl0KL6YrlhxJhmSUSBbNeMR8ehRwAS0ITVCY7tcjV8ZsIt6AR3cQchEvvBR1 oSCTp8ARJyfnr84snlxSvC5zcfFqSI2CAl5ETkAMvktKK3QnCD6Mc+tLEOswRFI4SrZsASsLFqwE LiuHDTt7dhiCEy6iLEQFAWg3SnFAhfdEV6ov7JfyreDS0MFLnTsXLLnaest3LfR7R5lBWdCCex0a 5WhdRVK86x4os3jZtDQvUHhIiaVIuOF3ISJxHDv2OnjpfhFRKZllXMQmnQUAQxfHfFhcPGXVoEGY eq5YvHp1fglmoIuHLABGiEvCk5sq4B1YFHiVyQw7JYMGrQcuW3ApQdtEyZb1mNvE7fotuKxcVSwN MyjSPb7qceurVHcLv8IYtL/mAq4IznmXCZGWtYkwFPMZwDEPMhOkFZbgbuzAhrBIhwICUVftUJAE WrHxYhLsDHIj8TRSpHPJNCOR42XfL15/Pbm7VP61lktYOBkAj5q/Lj8zfUrJ+tVTilcvKF6AajDm jKasWsCajHwl5AQ3jD9y99SHRGV9CSQEBeASTCnlIyJBVLZskSDEFlAWchdnruNcZXFxPmFxMQiq 4swKpAUCs3/3AdnIh7pyoKFjV692LmW5ZPv4OFEJKQsa5Vak3KWTzoxDvOMSZ58cxB6ZBhBWpPAi 4QjXHiu/+MUv9u37BR0MeZEC7hhIjKJDq5I/KHsVCFlfkrkg/9kpJYPW52dmTllVPGgytQXfwC/l O1EZc+rNZ06dykYUWr1gwaD14lzQpIkJKnT4bskHLmSFfVUIaYvBS3G+y4YoJAhAXhq0//zu8/s/ 2c9mlgM4hZy8dOzq1c4FS28aFlZscTqQt8Op7VTKFtwVRYDFpoTkDkyLINODNgaaQpVhlkT/ax7X FXZxu0+UBaTsO/aLY7+g4b3v9Qe708RQXeBkSczkMd2TL07Ga7/42SmT6UOK0dRdcgIsZC5Ifj35 zcnUFTG9Zm5xZ8wpFP+oLFh4gAQIkQe3mP9WXVn5eD7bH9iFh76HVfnVlgLhRpJmRqFP9te8Am5q 9u+/YNv4kJaGSYkwFPMZwM79WueXgpzss++qcruwsen4SYCFKqGdLKi1iNXVpEhikpTipNqvlmXU Vy0W8S6i0FeFFioLvYuO1+F1VWE4Fd39Tfjf7rA0Y0omFy9el7ng2JiS/Mz1KOU9k78+uc+Z95Fh Q02QEYnVhbflgGMBK4BlwYLHFwAU2BV/LMh/PH81WvEEl4r0VZYLIVlWtyIXiMp+eXuFM84EhW8J ZYn91/KZpc1+8VZ3QJZTYG5Ecz8b5RBiGIGkKAdOOJdIhyvWReKPpERBi8sOBrDCfEjFRdQF4mK0 wMDc1/3666+fPHQodWUyDC/sy8Xu71+cvCD/TVR+UUw5xdLv+2SFgYiuVsMWnc5k9MMMWrB6Naai mP48Dl6CYyX6wgEKWsfXoSO8ItMpCmRFSaHFvUBxqcZtjU4NqWfp2AWJnSsMjRQ2/H5+Uxae8ly7 60a24OZpi5zPhtx1+dCtmkpzwkjmFulvmRFJ9oz82bGi+gJU+P76sddff/2bDyIeXT90KF71QcsH DRoEbFi+vzgZhV/UZcTSWE2fbQ2cgzRapBxXAmFZPQTJk4iKdGqCGBDCtju0Va3KRFfVusxMvM2W dhaaFW+emcHnFeCCvLm6GgsStdZPXBKwNNHc73PiNk+GprChBdvW3ojN2PPyJALtHdVVJhK9PEgY EVIkKuELZPpIpwBoXg7B3yIOSbGF4iIWV2wLaHn99fuSH7zvwe4Pdn/6+kFDFq8uWV4yFLQMlU4X aMdQiVHXS41Wu18wMOUkyMgoWTB29ZAhq6AoiDfs0gQd0ttLPcHddfIRroevW7eFOTOsrVeyxZ1P BJeaahCDZUOWDYGWDj6JtVOtGxqnDbfcoUXbErypRDx2IzZjRwuulleMimBRziu2kBadLmKXC4u6 OmtEh4sA5kUinxb43AdfT36Qo3v3Qd3vO0bbO+b668fIBaoCHyOcqODggniFh0qeWrBgOXodSlZP nTp1RnpZprRmUla0B3yRrEoqXpmvd/AAVhJkSGmFU0KcEWK+jOgjuICV6v2fSlHOTEvHrl7tXGHo vKXOcgamu9Dm8uRETN+iUc7qt44SV2IJkuJqLhaHpG/BrqAvZEWMy7F9vzhp0nIfxAW8dCcv972O 2IQPHvwm06TbgQzsrgAiAWfomNs1AE2+nuEI5V58OnnKwIHdkpKSMjVLzp+G22nrp22ZlrElPyN/ 5fpsLGKbNo2fw+qkNC3ESYVfPMuFC9Wor6i9vbC/yqKQAJOAJXYYwmbsLhCpryUxLh9KH79sZt5f 1K9YzbYJYaFdCVTmpJbLMCShyBvHhBbGodcf5AV5ETSG4OhgXk0aul+Pe1Sb7vgKzBM8OPe+1/l9 D8p809zUKQMfeWRAUlJx9rT1WzKyM9ZngJQt2RkZ2dnTssFLNnjJKJlGiPLzh0kUEmHBFRJmolKN EERcqqsJiyoLxm8SqXPMZwDHvzhBkVNgNH+WQ1+4semymbnveGGIoKiuNEKG+ZDkSBKD/MYFwUUz IgPmmGTQQAWv+zc1Dj344LF/PAZM5KIfv04PDCNMM3zsJG74TWjjPnHyBCcPjh0bNeWR7zxSnlT6 +DMCSDZ4ybcJoh+m5U/LSMv/Iaegp0FdFi4c5uaBcHue6gJlQRwiKheqL1TzABnOIkpRrmNZ6Vxh qA4VOb3Iac48jMEVcXehUW4dep8EA8MjZgwiJzrTqP7WeGE7lPpbX1zw4hOF++4Tz5KMC9WCoqK0 dH8QKdM/7jt58h+BCNDQK73+Z6vUnOwxa8J3vjMgqTz/MGea+b7+hxm8TYOy5P8QndtEaAviEsSF yoIaiyJDbdmPTAiUgBaoS/XxgLJ0ScDS1EoQY4V7bGsN1zuBDLvgPpySe9AA8RpZPF3xcyGbKEKo skq/TD5bv+W+UP5syqLpMxKi159HFPpHwuLpyoNUFDcoKxq6TuIGlufEyZPHTpwYNe8RwlKw/vCp tDSyAjJIStqwDICyJTsNG4QILFvyp02Dsqi9vQCHwnSZF8Qiasv5asKiy0A6/KDey51LWeqFD1UW OeudV3YmGfaqHI4w5M8wKxMmMi4UyS2uyBS/lLV/a4iyJjrfsMg9TZ5R95dQBHsLOP7xHykwBObB 5x/85i8Rlv4RACkiworY45OiL6Dl5IlRox/5Tt/ypBlbBBbgkpadIXcoLtOgMYCFtGRAWQCLY0Wq /Hh/haJCXcHlQq2SIp6lg1evdi5Y9Jx4VRc5UIoXOeN9xy604C5K2eiWlikkikgsm6slXdJik9Ck hhbXr+Ty5Ra1YDoEYUG95fXX/3HfsfuUFhn/iDAUEBfiQl4oLSfgXPaBmh6bv0NlKcs+I7AIGXqb lvGMKEsaWqEyMGk0bdqW68zdghLNgZgwsyQncQjKIpZFpKUqEYZiPwOy8FCURaKP5kP0ufgALbgP oFEu6jgYetR1WqrNFf/iMmfrawlWcjWqqMuFruAasEBjUNOV8c1jTlnEqEBdRFrICjg7gcuxfaP6 PnJ33wFJG7KzDoOPDw0YUZjsYfkQGVEW5EnT8rdk0OD6vMCznN9NxyKs4LaLbtrPdKhLApam1pip sli6rHNCgguC0R3p41dCWfzhacvB6NLCFfNutsg3uYdu9SaIWMeVl95oIS4QFjx0Mvn1b34TmbQQ 88tfUFs4MYCvVj0hNsAFd/C1+/adGNX3O3dvHpCUnn341DNpz4hv0SiEO8OQF6VNIyzIkVB5yYCy aC1OVEVcLf2tOdzqD2zbftKSgKUJWGzWUIorLvyIrIAZ9D5lpHw/MuxwY9G9B3HhW9ShYUhqLrKq KFDE1dKcxiENRWDlPkJBUPCBqMvrmEX6xcmTv0A+JLaW3yDvGMCFGnPoke/c/8iAAemT6VnAC2ER fcE4vBJXW9T3IhBlbPmYqFQjCCFvfgXmFpgwC3LK4taY0bR08ILEzuVZLG2WOKQVOQGFx+weRwvu tCKBRW2KwPFzvCsojVhRuRE/LKxIA5SYFmiLpc5QBfoP0nKf1lEgLrQkgo1Iyze/CXcLbaGdhQqJ sdVrNbmotICZCd9hGHr2GTG4qixqdaksAsswlGBAC9zuxyIr7KKU8j6cLUVFIhGHrF6VIsuBBCxN eTZdqSpnXvKGhzNr7qzKklYEz+LHHOVDZCWGrtgktJZbvHloouIKLVo3sZRIKm/3CSySHTEXevA+ Tk8LHxJ6JPDg+gRV5YQQc2LfScDSc0DSYvTMPTMMyvIhxQXvHw4zWJBEDxNlQYHuY5Ti9n8Cn6Lz zCzbKijqWRq4RRj9LaadO/bQu06WOtvUoUoKLYukR6osaJT7GC24XqgRNTm4960AL8pNcOiCEdnw hym09EPJ8jNHC2afg7QghQYZv5BMmmV/1HVfl846ZUWBMUURVPAObp5/5P67J/RKyjx1GIYFPfxp z2R/iOthlBYoCzKhYcMOI5uGsmxJ+1gKt2xeQW3lFWZCkjQDFRlYXSbNT8QlAUtsacnVWr/4WkmY 3fnulBY0yp1Fc7+wIVGImJiwkBL/og+7Ic1QEoC4xpW9LaG6HAolXj7Eov6x1/nx86y6MDf65oO/ ROkW+REzZAy5EkwcK4xD3QfeffeEAUlTDoMWsiKgPDMMciKe5XDalmHQGSwCyUAy9DE7ESRZppRo 8dbSIUKDM0Fk5RCEJaEsTYShIkuVvVIcna4GoV1swc1iGPJDj5KCi4tEevtzi0z6pTpHJG9cJC3d loE6i6qGhSFa3GNUkmPJREVwobJAa4QRJcVY0Q8FG8By/90DeyWtO0Va4Fue+RDZzymgAliG5eNW lUUuwyqxkEx0xWYOA6pCcQEp1inX4QsSO5XBvcQyHIGxOou6F0qMhKHxK7CxqeY+HiO48xbfnccF OF5cct5WA5E2bnNxgHXMOdvCuOLTAmVBGNK8CG9IoH/xz+jvNkxCN5I20+KeeBrKMnBA0urDgAXv am4JyinYl2mwKxAYTBshDGVkHB4HOdH6mzQlnNfCrVw4RFlsYXwHr17tVLBw536nJMyBxLAoLtKC S1iMCpw69RYpsaxZPW5AYgKlF7U5Qov0c1srrrIiSY3LnSUhIhhS0JWBzBnsaNPuvn3/HFIWVRX+ iOWEpVfSgjPCyqk08DIMUYiRKO3wNC5EPIwreBYU5g7vlG4nNsVJMkRo1K1g4EM3M0RiOnj1aqeC JUcMixVwBRIJQfpWgf218wALvAp0xINEREU4MauiaTRjkQ2tzLH5XxYSSV+L73Cdb/XFhfgoKfe9 /k1cQ1nw5kAJaYtZ3H3LH7n77hG9kvKzwApoeQaBRzhhIDq85RlRlmfoWSAth8dxjSosrnha2lpX jhOHu9/O/5bUOQFLE839rrLCNEjLLKoqeMcuuOkz877mW1cVkoCyqFXxM+lQZqT5EBMiKbOEe7eD tkVnCU1XQItmQ5Hj0L59eFPPcmLfobGP3H0/YCk5I2Fo2DMIOYeBiigMlAVzAHiU09AIQ2cRfHYz 9iDqKCZWYLFb2TFZyywJWJowuCO1sqLJkB+PVGHS029EO4vmQUaJExX3sbEiKuPV6WxdEXcTkzBE XsJ9CqQjMAKwkBnJhMJDzqYiLCz1kxjAQmXB1JAoC/wJMiCqy2FcMk4dRsGFnmUY0qHss8x/RFJY uUUEIi425QxscCaI20Khw5c6d6owVCkZsxbkXARyrqU+fXzFzNx7JNYYK34oUpvrWV/ek5zo51Li tTquVnBRaNGFIYEpIkeLriMSWFRbmBFhRVpjbRFlOWrScujQVoFlwIdZh8/iMox1XGKCN4hMBhIh CAwAQlYEWKSLUugQXAiMlVgYhniOmacsHbzUuVPBslPnDCXquCxIgxAASk+/KeUuEsH3t2hbVFju eesghtbmfu4FIU2Y3NA19LbqWTdUCLTiYubYn06UxEdQsVgUJgXfSVEZhWvcVWE5tG8WYOk1oBx7 m3JAUADLKaBy9hn43GyoDB9mhmTKIrVbMbcKimZEEod4jplFoQMdvXq1U8FyXqeYrTlO6yvuHY1y y2ZuNALcdBArcwCFSmMOV5OikMqYtjAd4kIiRCH04Vp7pQsv0JMTtj6RyiLFORm/5FRReOB0iVE4 BQS4CChHcWcelWVA+Zkzgsszaac+pEnBlixQFAjK4bRnIDTsXUAV96zUVyx1duLipUPVhbpsSBeZ dfBS504Fy4WgZ1Fna5WW42zBXaYdCoaCeFvFREIQtAWGBmHHqY9fcJHqrayD1tlEBCK8zqIM3pAI JIsUBRZ/RMYgURTuqYoDhk6AFYjMvnnfgbL0Wnp2hUiLehYKDOKRwoK7oizIiLLYmmA1W82cLWdW YKrcsiE63EuJ5qcmmvv9gq0r3FpCRFhmp3xfJUPoMBYIi+oKjrm0YQ9oOVdtCwu5tnzIX5focDmG YOI7XPMsWvuHZwkiJV6FF4iLxCP4FgQkwLK5V6+CM2pwh8HRUllwFwoDX3uWH4IWVOcy0rK0FGee hYU4uetsC04b0s0HOZPYwatXO5Wy1GkM0n5KV18xbXkvffw6NsoBFF6UB2KDizlbXSRv0mO649Va zLRIIOLgkhAZdB2eZfmfoiys4BIUCUURQYi4cFmj5M4Si/DhxO8Mvr/XgBlZK8jEWXLxoSoLucFd HLdG0wuDm5Z2VtMgVuK0sOKHIN7bpXuEaQ03AUsTzf3spBRv6705YdmFfu11KaeJAvlA9swCLjCR j1RZuMdPV09xvDlGeUSmiGQDIEahr6o71YHufHSruGXyGoZkNZDOAZiyMNqopkiBRfyKptDQmM13 301YeBasJs+S/YiYMIU+ky2CA1oAC5RFG51EUZg7h4DBaUOgxBawdvBS506lLPXOz/qsmML8ES24 4xcBFmqJiorqiToUqgv288GZVbJXu5da+yW8n2uLpVblZGWiKYtEIPTReoPKIo0trx/D7S+DYcgi kOgJ7AoTIn0ffffdfXsNmJqVBVWRUJR26ixKcmJWkAxlZVNuZFoRyvKK5kBSXnFByFcXrDHTSWeG oQ5evdrJYGHzih+BbFpI1AUbmy6SRjkLQ2DGqvzAhaggBvFk7kPqXLRyx0qLepavvfPOwXfU4yIb 0uRZdUXKt2JZIC7sc+KDwoqEol+GLYv5FTG46lpOAJe+Asuz5lkQcxB6xLOkHUZCNOxMtnhd3EPv dpYkzZ6yhIOQLRtyM4kJWJpo7m/kVkRqIDjSKLcQngUTiBp6LBmistiCEJ7cztMtA+sUZZKI6JzI zn7z5KGfMwyZ4zAG2JsfLN/aPKLB8stjvwx6Fq3wSyiSCq6evXd01AmDJQuqcpaWBUkQhOTsdYdR uQUiZxmG0LFAzzIsC8oigSfCrBg1smzItVV2cDLUqZTFKYmXMfs+ly24C9nOorFHHIvm0GCFtDAK 8eRCHL6NzX1EXSyNpq5k4xiXsrLME7A11imnr/sJ8Soua3YFXHgWFljw/o/BbEjNimRC9Dzc6Rvg 4PoEyixQlsWiLKTlFOoqCEP0LGfSrnvmLJVFulsyhg27Tiu3VuuPFBY097s9kzt+qXPngsU5Wy8V oqbU7zpev6sevU8Z0qEQqPVbbaUr4YCs4NRTHKN74lAPiovfo0BtObluCXbEWJN8kDU5r8IStCoa ebTcL9X+X2rNPxSGLG8+IU5Fi7gCzASBJfNMH4BCZaG5ZbqMKq4qC2Fh3xymh66T+UN1tXoTlJhx XQKsdPDZq52rB9dPglzXk9gVhqE/OVhQe9Oqm7iSvT2gJDyqXYpkR1NP4MAx/Mlzyzl6FB2s1WUv KU1anOzWxXt5kCY8kvxIGc5gsQ/koXBRTrwKT1JTVdHa/zHA8kivAVMQhs4GwhDV5DBCEEzuMMwY cWCe6DrtXtE0qPE4whOdJW9uOJCApak1Zq4fwUuYoSqKC5RlfBqUxaKQVlPYjCukwKrgcGWcZ4jz L0+ewEcQm1H79t4l452v3fXfk8twmlhZiVTonVsxXdFpIMEjWaihvWUapFe/DMJCT+ycreZBAs1c DUPrmDiflWzoFOBIyzJYaHKZDUFZCIvTkiieZRxXgri1zgc6fKlzJwtD1hWniCD6OHsrynKd9j45 XmQ2CKDg2G2eeYoTouy0XBqXUanccnZByZjkY3Pf3Pe19aUFBUtKF7/zzs+xV5i2Fbh8WQv7c8mK tGkzJbJiv9xGTiRCtlRatCZ36MS+UcmAZcKIAauhLJYQpZ1FGAI2w5g2o5VF7As9S9rZj/15w1AM AigY4+RMENuepT5hcGM+A7luJsgTFrsDYcFelelZhMXvSwA3FBYc4a7nF6b24RXPMTwJbclesmQN Bo47xXE/iyvWJCWVJqXf+k/7Dv0cRyhqenzsfyoVyUDlwdfnYreN57GlkzeHKBXcRr1PFBe6HotH chBsd8DSs9eAfIElS+aG6FkADEPQdQSF4IiyAJawS/EjkeBipX7hpYMP6u1UnqUo0J4tuqI+V27/ 9Ub0a+e+Y3OHruxGYdHTUXkkL0695HGFfODEoWlL5oOW0jWlpXC2JAWjfPHixasmJx/bhzPx/unn txKVuVhIhqVkydiYBRuAffP57mjU9jtwJUSdZA+uNygp3MhQtAXk0L1cD88yodeA9UydWZQ7eyoN NTmB5XBWBr0tHxJY0rKgLGpaoiTP46AseqizeJaOXurcmcJQiqcshkg90yC1LFSWSbnvsGz7Doet HaKwUFF4eCHfeNpln5M4LfXkyjXjK6bOwElzHEBGmQE1BWXpzy4esnrBoO4o0GL3nmTQgg2fuM02 N/DBIpDg4FY+tt5DynjMf/iGGr/NDIGWpxmGeiWtz4JnEWAEFqn4D2MYQtnlLLwuJhUzhgks0e2K MNTAfhZdvdrRB/V2KmXp7XewBJ0ucAEt6dhfO5cuJe+uo8ldD37/+99HJ1QPGFuebyknX8pBvBQX nJ15MvXhNeMXD+4/eOvgQStWZmY+i29fUrBmk0MmqbQUfhebsXSnomCbyu4PPq9bDD5/3/PcAcoG lw1Z9xy1BYVf6omUarR+KwozFLAM7DUgjaBIyf8UDK3AgneU+gFLlrRvsyZXGaMaB1XhhStBHC0d vS6+MynLWofIcerJHy1rFlZ27Uofn56y8Z0e0JX89IKCitXrsw+hRNf1EA4+lSNz9UxdPWKXR6yu AyxbB2+dtXXfXS9Mf2H69Oljh0yZkrkYB6IuQRYtYwqjjhDyIJhRVrC7KXUG2ycgMMkOltpoGQhD dC1IzzUCyWBzP2AZBlCyBBj0yJGTs1CUwxkA5UM+xLIcXG+lTDdHaov4FdJiR1OJsnT06tXOBEuO 5kL+ME7kJj19PNtZ3skr1pd6TXlF6l2HuiJf5gHcPPmS5+TK6bpy5PKyNePn9du6dev0o/dtBSkY /XCDOyVnFzzbc8ZS/IhVr4uUOEr0VjaT++aDz4MVbNGCNWZSinFrEbViy1ILVcasy6jp6H1CC+7h FVkQlixkQIfTshiGGIKgLFQVfsxJ52FZ4xori5EiYUiWDVljZQcf1NupwtAcv3BLbRFjq4YFOTS2 TGaHwl3ZBWY+kpLKkg8ia+4DVC5efB+n0CkwPEP1zNw+FWvGT+k3duvWp//SffrTTxOXWVu3zpo1 PfnPT08HQ5vLk5KGCCyBcb2LRSotQOWb3bVO58RFOllkfonEdNXkmStBCMuZPgILfArCEAA5ezgb IQnvKOCekeI/YFmhKXJg8AFqioYhy5zF4SaUJXbt4JzNDZmtlfAjxICWI2juByzv9KjwWElKqth7 iKy87x1F9yaYwfmoZ3CQx41rxg/5ypdfePrYIeyuft994GXQ9OVPz72IcDRr7JQpm6FPq8OwYCtt RiXZHpk5EuRF9vLxPYukPzQtygqLxsCm615dNlTeB12ViEMIQ2zWRiEOYejwqQyAApFh5V/aWaIX bomKQBNo1+7oU507lbJUekoi2ZDmQaYs6Kq8CbCguhaApbR4L4IQj4niiWI82BJHAL1PgelzJn3N +PX/6//zy9fFiIKWP3f/M46BBzKDQM3YQVOgLKux4XrjQVjgZTDACryMzAFYQiSzzCorMt9svFBZ thMW+tusUwhDp6STMkuUBdYFDwks6FJYEQ0WERbqCj2Lnr7K0dFLnTuTZxknsASMi0ubAQ72qlwG z3IwM8BKUlJB19RkksIDcnkCAw+h49GogGXJmvRh/z33Lz3+cvAveX9Bm9xX9+196+R9f/7zff98 358nP718HqBb8E0cMmS04I7evV0e4kbsxAWlFzdhJBaXqZCGHo1Dcq/r1u9QWbanirJo/5OGIZRa UL1lo9wZLGlly3YkLJoDWSDC3cBpQx2/1LkzwVItdRZPTOzOrnreQVflMrSz3LMuDMvcVBxyCVT0 lFycSCe4UFuWrBl/LreoaObMotyiXNz5y9+dvO++k4cO9Xn6R1Oe27AdwpI0iHzgDWc58I7icr3S wjxJN9iWmi63ApPSrU40e2FIzS77tUf0mrFixfssszwjqQ8a5MSzoCCXhbtZCEXSzrIilAeZgfF9 jJw2dAA1f46OXurcmWCpcXHHq/ITFHmrR1flOmw/eFd+MAwlZZ6cizPHiMr69etxRi54wfmpp948 nHwRlf7H/+t/XXH2vxblgZaZf3fp1KCxY6dPmbphwsDtvXoNwKkMpU99k0d+CCR2Q2UZ6qmNnPOA Mh22JHQWF7LiGxbzLT2OzkILLmBJTYWJXSGNT4g+dLQZEBeGISgLU2cUcNOihiEzt1CWj/xcqOG1 jl6Q2Nlgca5WLAvflBZ2VT4MZblrdRCWNScOXXwTp/3gqA2cT7iA8oKTx+BdMP27pnRJye1Dnxoy 5p7c3LzcuR+OeWrr1nlbBw7o1avXCAzCMuh5ZcSxIneHLh+q8UgiEd+SvzmXWyNLUU6LuOpYMIeI Rk6GocEShtLfhmc5e0aXHx7O4A1BSTvLTAipsyyNDyqLTR0GAtG4cXV6QiLfDhxIwBI7G8JKEC9d dkmz87jYMnl40V097goZ3Iq7ki+egqrgWEIeZ4lzxERcIC1n3i8tXfJ3//2b86aW5OXl5eZd3Lp1 LPLorQN73TLwloEDR4xAGNqEMMQAxCvcIPzwg6FPLR9qPsbV6ZgQ6U6m6lpYYmHHnSlLV4ahvr16 PZvKlSBZUJYzUJYfsisBnoXhCG9YyMqa3LDDQWWRdNnzK7S343iAjNHSkICliVl3wKK4ONsSUpbx i4q+1vWuM5g+TtqwISlp6YwZSVPycPIlT99evRonh60GMYPyS+B1IS2TAUuP//j65vKSu/Jy78pL njIPsMybN6HXQB0j4I6Xg5MxZMV4kXvLn3rKD0RiaR58nlvjunxIOm+VmhNS/Qc1d9+PlSDli+lZ AAuatRFytriVIAKLzDljUWvaKR8WTYCsxMJMiFYXa8zcsqEDezp69WpnCkNVf/RR8ZNmiUL1CEMr cfTqO3ehzlLev//UpIn9Ro/od/LMmOySBY8PKV6FUTwEuIi2fHjqTFpSafrBv0wZ0WvsXbl3nc7r /svrKSzzqCwcE1DBFVh0iKooMwaLeF17f3AuSy22z5MuG2JIQhhiMwvqLvO0BXdFKjxt1ik0PqGV 5YdS7lej+4xMREu/9nUOFt/TenkzeYGyNFi79oGOPqi3U9VZqhori4DCKzTKTcvLu3Xv97NLk8on Dn5sav9+gyf0ezp1cnY+TktetSpTcCleLbRMPvVmdlLp+K8dm4qtDYpzc3scnb78QcKyFTGo2yOP ABYoSxnCDehgLsRht8ufGguILE8ShDBkGw5VlxOUFWuSG3WCdbm9J+7HLrjoqlyhYQhonMrCtoPa imthSNtZkE8bLK7CH6iwiLTwaCqrsjQcmJlofor5DJhjkUAUKLGQlSq24OZ9Dd20X3u8tHxWPxkD 5508OqZkwYIhqzJxFDsa41YNKX4cZ7aXYHvraUmlS763dey8TUk9UekfOnbG5nkzNk/tOaLXQJw5 hgFlASyKiJycKfoChXlqLMJQsP5y/YO/4OEz//TOP1kkYka0D+ZW3AvBOQZY0M5SvKKPtLMMg8fN SpvGnsoPh52l0UUnLntwuXJIlcVHxQKRK/YDFsmcUevHnY5evdqZwpBNBGnN1qVBljuzBTf3IJYb 3pU9Y3T/wf0f69dv4ogN+WculuRDWMgKaMmEtsDmbsme/OHjSWvS5wGWKZvvXj528+Z5S3tu3bp8 RvnS8l4DBn7nkREDtwssxENDkN4BM089NRYQBZQFTS9jBg0pXlCS/LVbsSOYW71qK1lZxJ17v/Q+ FWdJUe5UGqq1WWn5zJ+5oxy39pGGfwgLJolY7je34t0Tt8KrcXaOmdmWBCyxpVVTIUuaLfzYTRV6 n4bpMWbpPfv1Gwxt6T96QnlSWUn2gmJ0HixeXGG0IA5lw+Xmbxj75X6DB89D8Hlw7+QpfXuO3rp8 3ox5W3uWJ5X/zSNJSUid03EAL0kRVTGFUWVRt6IepvugVRUFaJ5aU1BW8s6t1BPpetqHtWWMQfS7 yZh0ntCrfPUZhqEzaafIS/bKs3C5WGO25UPoizX3c2pIw5A3eaiU4AG5fXEc1pjZvv0ApqMXJHYu ZfEb47wCi/rb+orx6ddtPNh11Dupa5Y+9hho6T94MGeOl+QvUGGpAC2QliE4p31B2uQXXvjK1x+b OHrwvM1j77sv9/Tzm0cs7YvulgdfmJG0eOlg7NKEcs2zoikeJfjodsiLKotaFd48X+bVjNcMAion 4FtGcaXzPmy3cRS0HEULLjdjH5C/os8p9GtjtSpgSVvJrltshIsjHmTDDbfSOceCUKjIL3ZFEqJa iop1KCRgacKzxVKW+qpd9ezX/n6PQ5wcKp3y5X79+/ac0BMqgWACWjQKEZZ1q9DdlP79vV/+yte/ PHhi/9ETh0wZ9PS+3FtRjRvR9+7BY8dOTV9etvRvRhCWxRZ7NBLh+vahhIXKop5FpWWxXwYsnSy9 3qMYjUAJkGFGJP3ahAWkIA7BpzyTDWVBGPqQsHzI7XxOyRIzrnS2MOT3JWgMAigv8ganDTllaThw OmFwYz0DG/0QpD0s8C3A5E/Ulir0Pq3YOOrQQZb7S4v/1wt3T3B/8emwt6sqwEhZQUGB9NqWvnHX C1/58mP9B8+bN/bpqTPG7ss9tvX+CazbTrh/87zNM5KmLmV/JWDhefBCCjXl9uuHDkVNjgZXHa54 medv9xtokhZLFJIaC98w7Yxl8dqCO6C8BM008Lcfpp1Ny87KYBiCR8lKO7sidcWkSejJxdbJWEuU 44UgjT60tqYr1eAFy4bMsKCG29GsdKIwVGS9K64rQQIQaAEqu+rHo1/7dNce7wsipY//9/8c5M0/ l5aWAZJN/gxj6fe//8KszRtmTOi7NH3qmgFjf37wvq133/+dgUtHjLhlRM9588pKS9kol0l/60LR UAoLlGX5gqfG3q6YqLIM/Z/TKWA61lx8R8otjEUnuJvcUU5BowX3/oEDyg5jbgjT3agIfph2Zssi ONotw1ZkZW8ZDj+VloWO7ewMwILVq+FkSFHRkty4F4/4nqUhAUvsv5YUV1Oxwq1NIYq8sKty0ulD XY2Q0mn/8bUhoSnF0GT0mf9TMgPlmIGj+eim9QcPdZ+3eTPy5RHlAwb02jx1Qy8haxUUBQ4XgqIx aCjC0O1Dx36PyiKscAztPvTLg/1/adA73Krf4cKFZsBlebfvfGdEUnrq25POpE7Cjuynsp85k53P drmslYvLuBiltCwTdRfu+5Q1xwyuJssuBFkcGlfdxTr7r8rq1U6kLL39LkpztaTnTwxHVcehLCmn u3o9laXZd20NhIcQKggwafnpSUkjRmwvL5+6NOnZk0fPjJ23ue8jEx4ZCFx6YS4RuRD6tTVzliuC ggvGgrFPaS6tYWjo64u39vOlZbXBIrwgEAGVfaklU7bO67k9PRubVR5OPXMq9WLamdRnss9kpW7J XOOtQFlSnPVhxodpK+YYHw4UMyy0LHyXCURzLR2+1LlTweLVa82zVNVX0bcAGLTgjp/5b32AgAsI q/ttjkDE/zA9fwHC1YylA0aMuH90Uvmgt8eM3QpYHpkwED34EBe844uH0Kow/PBKSMH78u8tMGVR ZK5/fsrEL0/1fvT6f2IBl0GIG1UewvHfB/eloi3hw+wtxcWLitetWrky/1R29tkzw06lpn6YHhS/ 9IrhyItWVAZ6cF0AMoF5EQDZcSDCy/GEZ4n5DOREFG6rFJmqXWAGu+BWpOSGOp/GLucuGtFGaVl+ cVlSKTpaZsyYsaE8aSoacPvNunv0d/o+MvAWkiKsJA3pzvyHkIzBzfVEBdcLvjfWynTCyu3dx078 8rectJSWqLLAsxzF+4mTew+NWZA/+eRfevQ4evTMqez8lcXrMDLXFRevHJbmoy3/y9KCRWcPr8Aa M1eCC8QhyIq8vcgjqeTEO1w6fPVqJ1KWOTqN6GVCNLZCCpQFLbg3ppwKuZSl/VZFI2VTQfriVeuK CwiLDsw/L5mxoefUvn373v9It1uAC0tyaMFFo5OGHrErerscniUAy+23v/BY/y9/ZcPSDTBB8D+T f+4dTUVZ+dqJxVxEXbB6789H4Ty8ucnJ75+avCV/kQCT2chUFWxJXVHpl+Gcq/Us7s5xOy0IibL8 MaEsMZ+Bc37RFsj8SUIQr8jLb9HcX5QfhqPn1khpYZm1Aon0qsziNYCFC51RepVsmqO8vHzpCDQ/ qWVJWkBvi2TZMFFkln9vyFOaIun48fR+j30ZteB+/ZhAFYx5h4mQ+BVkzqkLFqtmLFm8ig4GxyWe PJacfGpM9pb8lfkAdgTmKwOjFBPTO9XgetaWTgWVW6oK4Qn4245fvdqJlKXSNIX1FQ6aW62zVGkL 7soIJekZ+NstTdpUsKQsvQJDynPpuhSelOi9Rn/mpWOpLE5WzLKgzDIk6FmGXj+9X7/HHkMV8LEZ +CGZ+/ZKDJLLqJOZS0slQLFqU3wrPgFYTpycC166j5mcvX7x1Pu7hf/LZWcnOX/rBSMzLlKVo2eR ECTMfDuhLDGfgZ226kMxEWVhIsTbKrTgZhYVR8CyabNKC/ZeIShlfCvDYrSKxZAXkZTY2TVbcGFr JQ4JMy4MDUHqzBod82fOAEBZQAumotgBgyhkpLAkVzIjqbSnEomZpq/Bwpw4eRKszJ2LeJT8/Nzr Jw6eKDC5UbpkXXYgW1ZMSAnLceN28o6vLA0HOnypcydSlmqbaxZCnLIILVXsfZpdlBkBS9IMiwJS v7WBFfCUl0w63CZpUVicWSEu5OUphiEEJ4tEQ68f1P+x6WCl39+AjFW3otKvBhdR6MSCqQNKe3q5 8eS9Ryksc08IKt27z71YMeB+dGkFWClNX5nhxyCrxTH4SAQiLjhOU7RF9KXDV692IljOB5RFQpCW cEVZ7kBzf5GiEXz209lkib94sgJ5KRBgMDkEWrjRBs1tTHEpYMLsSYoGJMBCZUF5xSwLYKKyAJbH RpdWnESoOckoJG+HSuaNGKCmhP9IxUHoyoljUJZjpOXNi92njJ7Yf3DQtaxJ33LGzRi6Ej84ga5U v8gx7sUaJEJWZWk4kIAldhyu8ZSFeDAVkhjklGV4XmQYQiOuqvwmmRgSXISX9KnpFZIILcHOTzGQ KR3S3aVCJipkBR0K32NRjgEIyFB3+vXHQCT6m76DRo1CmMH58GpODs2d11OTJKFl08VRpEVjEBYj Xbw4dmL//oNpdWyUlqZvOepVbW2amX0J1BQEIVxdcKTwtjLhWWKfCeIanrwZIZ+Wm8anr8w92rhm qzNC5aorNgSXinSFxOXPmkMHVKkMeZDZW6cqqixDlkNXUHEReQE+Y+fdfzdggWvpfhTCQWnhOHli 1Imxs6aPHS288ifD4oIVcywXky8OHdwXvZ9QlnL0lusom9xDMmdLhnSu2aIQaBk3jsqiZRaMBCxN rAShsjD6IP8xTeFHckFX5cLciBVm8iLp6y+wLF2zdOlS1ZZ0aMua8dyHBbkQ3iSH9oa+cJn0sZ6/ NWBuHwvPIpQgRmli3X3o4MH9/+axL3/9l2/OBSg49UyFBXen9//KV/rBy+gPXHwIwkNaICxgZfng /hMH95s1YcCIqRMHM+/GWFJy0NXklBEWbXlDc0txqVHLorHo44SyxHwG6vxuSsmY1a1oHIKyTNt4 cOb4gDQE7zIEbcJlDd4tEqXDtJQmsVqLP/2l8mIVlKE1gUMBcxX+oG+5feyQ7y1nCMInZWoIIerv xvZ/7Jdf+4+/q0ifLJaFwYbm5OR9j/X7yle2jhgxuK/8wPS5+DRQASwXk7u/OfaJ/ohgg/v2un9i X/O5pQUlPdTKQl/YvuIBwxAEy7KzLqAsHb96tRMZXJb3QUlAWeBaAAoHlGXa6b0Lb1ZD22isga5s 2sQ33IO0wOGm066UlmucGjFj6dJNS2f0RPlf9/EBOUOsyhIMQkNvH/K9IcslG2KiJKx0n/vgV+/6 t788viSpdPIoKgv2zxVgjr3w2AtfeWFwz8GPbVVYkveBFfUsFy+OgWPpN2vwxNGP3D9wwpOSNJUm lfWRMOQ1UUoWpLKiuXOdqAqmnqksHb7UuTPBIq0rUsY1ZqgpqixolEs73XX2bVGlpXwpNGXTmk0c YEJSogoqCxKjzHLGInCydMYIoDKCd4SWxZERSKH5HpSFM0YkRYq7rw9d3OM/3jglc4KZdCUgRYg5 eeyFfqjtzhvcs7/CUvAmGAItQKX7xTEXSwYDlokTJ/btu330YPSHY6zJ7JGqrHgDeiK4iLLsBCzm V+hZOnz1ameCRTvjNPo41yK8VFWhBffjfzs6+7Ybo2TC5fOmPwtRsQFpEWUpo7KUFchkHmARTenZ c8YIDxbzt76wiNKYsmilBbh0v74i6ejGlapom0reYQCiZYG6pD7d77Hp/SZundUPCyT5r0xm9ZZh CLoyRpRlMMpyo7sN7q9xCtpzaIWWVLQ72/QErMg9XFVBULpAWbqw1rI24VliPgMmKF4cEr+iysIW 3OtOz334C7dFgWXDL//vr0yfN2NTUummUhJDWNIrmDV7Nf7STfC+IEbjkPyMzFD4wXL4obf/eDmn hr6Hu2JjpIw7dGpSafYq968WvDkK+RAPs2Je9HR/lHb7939snqKQtADKIqx07/6mwoIwNHHC/f27 6WTUmuJRc1e4/hVCoxJj5hbasnNcFRXFjd4JWGLDIsrieVv1K3yvq2IL7tnToxbe3KVxW0Jpz8f+ 769/5cvT52GiOWnTJlOWxYAFk4mWhfDvHoPELF0qFfqkIQFYFI+hP/4vy5d/Tz2L5EG339799sVJ BesCrQZlJ0dBWOYiCs1NPfpnhKHHpm/tO1B0BZHtJP0tcyEIy5hBfftP7z/x/r6PoOtqIHdtSEq/ eGLuCmvNlkwIUiLywigkydDOXTAscrkaB/V2puWrAoqXNVssElzqq9AotyIvef2NN0eBZemGr/yv r3/lK1+ZPrWsALQwe8bkM4txSUujtbzMKI+A5fqn0fQ09Mc/vv7H3xs7Zd4QKcYRl6fR+TQjKT24 i13S6r2c/zl2Yi6IOYb5xa2Dv/OIVFEAS8GxE8lz5z7PaUTCMrg/WZkwodvARybcP7rn0tLig8lz s5xbEVUxpyLultjs3KWgyNWejj6otxPBstGa4qy2olmQBqI6Nsqt6LF68dLo1ftnX/j614HL11/I zsYrW7oJrQhLZbJ5TbTWS82jXTJELn45HbTA0j6/9YZ7Zw1hKvQ0otC3vvvdKfgx4QnrdEw2Q1rw noo6y9bREx65f/AEC0NJC0ZRWJIvIgiNGbN8a//BE6EqaM8b+MhElIDHjjlxcW6WVXAFDYtC6m/l cpycHBFeDnT4Qb2dCJYi1+pEj+s5XMQgRCG24F4aNVUkIdpAjfS56dNfeOyxPmlImtOXFa/jBoNJ SzIrok0NyWML/Prt8v/2X556+lvf+vGCKX3vvXc0JhK/dcMN628f+uQNNzy5PQlCVcZvsNUDBWNu xdY+Mk4cnftmydbB/R5T+0ppmXwCsiLCMvn2kln3IwZNGIjO34HwLV//+i8vJienXiczzJoyU060 RU5RobJYFBJcOnz1aufJhlKkicVV+K2+YvpCZUmZHIuV8r6jR0+YOmswlimufybrumkfb1mXyaVh pemZ6f56wgjIBjnPgur+j//H95Z/5YbpQ3rOuPPJO390/e033Hvv9Ov/66wnZz15Z9KaNUvTCcom uU4qXXAr63EstOAai+LR63L3dqc/6d2ZOIOV2yeXDB3SE6IyYQI8C6Sl31eWX88gdZ2aWsoKfYon KULLznG1EoZUWbp09EG9nUhZeouyuNlDm0BECKLBRVdlekrjeUR9/XtNlH4TVEtHT5jR89lnN/Tc MFUznvIym+eLokZsRJCx/MswK//jey/0H9tvbEXmDffe8K0fT7/hS3/T/1t//tue939pYNKmNYsX o7tpaaaEtNLiUfAr2AkKoQgF26PH0Bk1Vhczkaj8Y6yxoPMJP71kdU9QMqHv/X3hWgZvndJ91OTJ qdeJrrwsvEggsiY5qbKM23kcsBwBLcJMhy917jzK0ttTFfW0gISkyPjt+PQb75kSIwZN6PdY/4mj 4SQnbMcyj+2svfXUIljphiiexWxP5lPLly+Hr8Xlx0O7L//b//Ll6f2+Mv27N9xw75N/w/Gl/o/d vfSJu/unQ6XWL8hEQq6wrD4EUUEkmovupxNHu97X78vTtcyiKB0Tx4IgVFIy9OKHQyAsj4y+H9Iy omzKxckLJh/9mFGIWOhEs2dX7M4HMCxKCkYCltjN/d4cs3YlaDnuVQpLHboqK4qmuLZ8fWG0doGx fXRPrh6TaaARQAW92VgtJKOgvDFgi7MX4PWvSJ83ZfVydiKAmUGLN8/7H2O/+93vfuW7N8x68ksC C3DZ2vOWvl/61ndnlS0esjyzrGAVadmUT1jAyr6DyavKFt/1dL8HeyaVuv/LptXPJ6thuX1oScny kscXTwAr908YWF5asHjKkMmHjn6sXXE212yFfolAcqkFKdAWTZ9/laizxHoGPrNeSj8LAiZghbS8 lz7+pr/M0wU/8sbFHLaiI5CtqK5MACxRIHHYFGR2veee79+Tl3cPzuI82rXr9UOXL99cVjblu/d+ d/r0J+eNfuxvvvSlL/0NiOk5Y0rZ1AlP3jD42cVlmUOmli0mLGsG7UPWPHfuvneS05PKD9/1reWZ A5aOAJuSNxWUCCuTJwOVktsXVGC+oS/2/cD5jOj9XDz50MFRIy1lNiV5cScwCUgNMDFSAE2Hs9J5 wtDIsLKAEzW5DEXoqlyW9yNuX2vDeIG8eAJjerN94Ax4lnIyFWsUrP/3e6b8KO+uvHvuuSfv0H97 8O2/+2/zVn/33m03PPfkhrLByzd/6UtPAJd+U2GAnnuu77fmPbe6YFPZUsuHHv8apOXYiVGT0RJe /O/33JeJFQMjlm7CVAIMcOmCE8fGTB7DIFQylKwsKe0569nx41HuKS8rTsYpwudQhzNlsblDqIra XerLEVEV5aXjFyR2HljOaeAJpkFMm8XgCizT+24L4GJrxURmQlSUb5861Tpfy2MAUzBlCg7uzfv+ W/fkvfPCz/9/Y19457vfveHO0uduuGHqhhvu3HT/3zzxHYShgVNm3HnvDbOGTL3zye2y7l5Mc8Vc 7JtwYu9FlHUr8v79nlVY9bgUdZ2BPTcvhpylLyhxrDyVmZ5eULqmYtmN48dDWJZkDlk9ZtTeSsuT X9wp2uKbFsWFhkVQwVXHL0jsPLDsdL7WLIuGIMXlp+PT1+VNR7YTEheNSCIyIWA2TO0pUSoJTia6 upSWwwFn5v379//9rndO/+W/TX/+yzc88cTUJ++9d8O9995b8MjdI+6cMeNL25f2vPPOO7c9ecOd 926bUVCaNONZCW4FFfkXD40qLk9a2ueNmYBuKVkZsXTE1K1TUQgsWFzCtLnkqZJVZegQLk1f9rMb b0wvxWF76AsunnuwUktxrh7nvIoVWnYeoazA4xKYzxsspy9VfeELN9988+/HfXzu4zm9c3NzN258 o5Whdqd2r2gG5CIQP8A799fOnY5puW6yRiwYjeQB9xC6nUDJ1Of6liMTUpMbHZdSdO+WP3MQYSgv 7/9764M/Xt7v3iduePKG74KXO7eXL912w73bn5tXuu3Oe2/pdu8Ndz5x55KybRum/AgvPss3S9NX YRpgwLo3+lQkYVegAeVLe80Ygb08xrLuXzZoDGLQUyVPLV6CBQbPPvyzG5fduAaL39hTXrE6VUiR 3jhcTFoCxRYFBaTgraqVT2Qbvi2pDd/b3Lem1Nz8hcC4+bXaI7XHx126dGlmSsvTvvOmLPXiUiT6 iLJQWtD7NPyu6ThbauI2cBHkpRfKXiyoY8sEILSdWdF2bNAPRDZo+hxrlPfcgHxoyurVP/ru//Pd b/X/L1ufuOGGWd/90Q03oMJ2J/TlzqWLN91y55O98H7vk08XJN3Z///51vayKVOnzrOG2oL3D5cB FMgXyESfzObN03mIUdmC20ueeuqpkgXp6OUsePbZny1DNzBYSccmMujuByDqUCx7ZuHWq/bvrFZW KC5HGj5XsBSdnx9ExbsPpbnttiPjKivPzWlJwbpaqyuiKTbX7HkW7FW56K7pszDlj0Akg8RwDJzQ lxUWzOti9Oq1Hchs+NG8CbpXggdKFHkp7zkPWdPUqT1Hj/7Wd294cvrWwV+6YcOSsh9twMYu96KE e2dpWVn5Ldu2D9i+7c5b+m1eun7wC1/u+71+sxYXWFpeml6QhM6qcolN5Wiv6rmZcWgxjhB4Kv+p kiFogVlSUL4mnaysgbCAlTUFq7QYx5nmaCXcalMWFlu6dPyCxCvmWXIr9zACyVtUZvDZL9yG/sDa b+cUFeFojuaqBjWKCvTEq8WpYamq+wGUZeVd/frNmjW47y29bjFObuk1YtuECUBlA2mBvMD/EqPn ps8TK6yJtiVMjXAZAFQ2T53aF7g89907S6f2nT6x/9SCpSjwJyVBWO7tiw3fy7dv2F5acOedt8wY O+tbfad+edaM0Y9dH1g2NgCqwh88gL0y6KJBQlQ2pOSpQU8tWFCCRU7lS8rKS9mxh+klZM8IYQXF qirelZ8I8bEXCYu7NFxoTtjb//NXJgzlzvk9BMQGXQuRiQWN2Jr55+fk5KydlBd7JYgqSr2rrSgo GofQKLfwrsH9Z/VnHOqluNwy8JG+mBQajc0R+oq8bEAwIizzps+b4HsbscBRnEt5T3DSdzOBmfrk nSPK+z7Zrdu8rfAsSHy233vv9lkbNi0tL0ifUV42/c47pw76yr3dJoweXT513mZth5GBBhl4lvIB kJWpU1E3RiFmE2ABK089VQGzu+TZDaXjCQvf2Wy3Zp31rwQmmnUOUetyF3xWulyFBYlXRFk25tT6 qEQgo9REJwdfuuePVVXf3tkbWlMUYWvqiIoV4ZxrcXEIjXLTvtrtS9CWwcCAIQi8dAMpOgSXnn03 MCANHDhv7MS+A2+5ZRvtjWVKvsJ4L/RS7MEhytJ3c8+e827YMOW5ETOmToWkDNi0Jql8zfYbnryz AO28BUkb+vfHjGK/Lz2xrduTW/8Wnd8zyqQAZ/YZ+zAjGerZs+fUntKVnVkCVhY8NaQgCdvDbHh2 CZSlHCuxsVsY6cr0/IpXW7EKi+CyH9HH42Vn+ytHcz+x/ZXljd71t92slyZGgJnGinPzbfPnzz8S 7l5380CmJ2pwlZa6ivTxGf98yxP9+6tpEY97y8DRE0dPnOjhAmJ69gU3o5+bNxFTd9smbAiWZVRd Ain2dry8kBWRlp4jZgycN+/ZO7eXwdreuQY1lU2MRDMKCmYUJG1/4sknntjWf9aEzf/le5tnbFra 82//dvMMb/svqEr50tJNM0DcZoGlbMFTC4YseCoTh4xjW5jtBUvSsUAFLZ7CSsFsabe1KWbP2Fpk 2jmu5kitry0dfvZq+886/+ZSzW024GObQ0ZoUl+Dq9C4rTrcY1qH+ooXeqx0a6ywUW7Yn2+5pduX +t/fTWIQDWw3QcXhQnmhxuCR50b37dZtwnPPTQgV8SyNdiFpBJRFhAVXaHocMGHGt54sL1s16M4N jBfPEZZtSHNAyzb8kxvGlhX87d/27IWyfs+yghkjdFaRr/8IZM0stcDgIkCVpmPb5iF4K0sqWFLw 7I+eXTK+Yk3BEkQkXe1WAb/iTSMGmUHZHx/WUFmMly4dfpxmu8NyqRKaYLC4W4+d5rRGzbCGqD3j RobjkM4JWRXOUWK3bMF9uhdoeWKwwsLRDessFBeTF0FlNJRl9IRt2/rOem605Nl+VUaLd2Z7R8Cz 0LZAXnr2RM7Tc+ms5wYu/VvOFkIEoDC33LltQEFBeQUKeAMGVJShX3PELbcMWAMdQjrkdeyxHkdO cL15adKSdTAsQ4YMgWMhLM/9aMOSG9MLYG4xOcSxZrhzKJ5pATyu1r9zZ82RLh+AFcGloeOXDbWv Zykatwes+OO2CF4Um3hi1K7KX+8Mm11tSND6is+KJkRswU3FawVc7n9E7e0tt/QVWNxgTHpOY9Jz ExGrnvvWrL5yGGKwKuNqvUBmBN0KlQXEzAM2WCIyY2lZzzJuzIOZbMBy7/akzFWbZIPtAUsRmgZM eOKJOzPzM215gCrLpk0jUMQFLiOWAqIvvLxFWIFj4Srr7RuWoBEHC1J09w+UWx6X4m0g/lhIUn/7 Yk1tF8w7m23p+NWr7QlL0Zw9e979yfyfzH83RAw/cJEpFKFiBqkvzK85V1lZGe4Ek2QoaFiEGLli o9ylouLtIKQX5vggLrds69bt/sEYYV6ICyzLc9tuueW5P09/TnJpLbmEqr40LwP7AhSJQlNhXvpu hnHtuXRzzzJICKUFNVwk0QUVpdJTqfMJ3Z64806sk7UljQaLnKAnuACWJYXnCMsCdgKvKZixIX3N jUvSsaUdPsCmZZtKyxYBFC4TkgTImPEsjCoLtEVp6fg1Zu0HS25OLQ5OCoyfQGV+EoGNkxqPHvga 0ZqgHf5Cw4tApTJCWQIV/oC2iLKwBXfmwZWbNgCWW574EnxLNwyBhcu4lBifm3kTcWDZc+tnsdqi IyQvOpk0sO9mpYUDqQwy36mwqQILN/7a8BzDjYgHREHOa73z3m4EI1yyYTEQj8KzbN6UtOb4ucfB ylNonWP59rkNSyrQwYv9GxCT1pSWVSxeqQ0JenHFW0w7Exy81UFYgMoHQkvnhSW3d30YlSA1785/ t7HYqNz4miPYiKupIiqRynLaVeAi4hC1hcrylx6LS1fNYPx54on7ycoT2CkHfbfCi4CitMzjIsAJ sKTPPbfBq/OKvAQbHBBTevY1XCAskIXN1IapPcuwlBFAVIAY+BSBhe0OnEUYUT76ifCGgggspaUD yreP6FVajlQcnmT3//X4gqdWSedL6ZoZy55NX4I1kYSFG35gH81p0sDiTIofj8gKRlUtZAW0iLZ0 /ILE9lGW073rGx5teBRvWM6yB2+xxrt7olEzP+ht3t09UlkJK0uRM7cR3paR6CEoS9Hf4VkvKO91 CzYnfeJLj3Tr9ggYwTkypi2KC1VmHq63IU5t2LZtm9ob1ZYQLgMGTOg7GsFnNIDhwLIe1krQlDK+ gsuaqS8iMbi/aQNjUK8R5Us3PBcx31RWXJFUnl4GbVk6g915Sz7duXjVYolcSdgcc8aS8ajHlS7R zT7wUBkMrpsc8n2tiIoAVAXD8gFtC5Wl4xcktg8sdF06HuVFoHm04R+ADN/DsYkf/WTPT2BuGnFD ZjQENVaWFJs5jHS49C2/hbLkpZYVpG3JyIQdQVL0xP1Yr0NYBBcvFskH+BBAAZXtNjWA4GWhSKkR nZmweepoWpa+KLTgvWcvgWUqqvboRgAhtLQ0I7Cv6ajqo2ETrZHyqcAoXbxhQDm6cwf0KpfeKNoT +8ak8oLy7Uuwl8OaTTyrBNqC7y14OGBu9a7VbkVwKk1ZPkBC1OVIZ4WFNbR350NTPGi6ABhQ02XP o7hAayKhcQDB2IQSqHoPlQhluRQMP2F1qXoPypLboyx9RdrZrMdRnGUoeuJ+QQU9/Y4WExfCgtQZ NTmZGdBM24ozZngRkkYgy55KVRHTgpxoxHYcYLR5hsuJ1bkw29mUtHTbthHlsRqpLI1uPFW5Bv4W STPmEmVWCHNDhMWPQXQqLm+WRyt37txViyjESERl6fDjNNupzuIqtXQdYAZwPOpjI1rThUqDS+wI 9RNEqD01v/ZhCWdDvXXRhzfRHOCF/do3nr5YkH79gtVDVk2Fsoi6YMc2HxczLXAsGKO7YTL6zgl+ FAIdQo1YF7nZ1nf0ZmTZVBeEIzjcgb16DhyBPhgbLgZxH6CC57YhP45nYDm19xMwj7gBhEBWZP2Z wvKQV4gL6IqCYmHoA4lEeD/SWWGx4kmwvq9aE5AaYQZDfA0vjcb8Wj8ENfIsOdZu6yPjEue6qm9g 5/68qUkwkiO299o+AMLCy5cQhiQOqXMRz4LuaFyPhrBsGwjL4hXwdIIgEI1GwK8QF7gWVFpwLNrA XgO3l6OUW+5aEBw1iDMztisCuOdPC+nnSwMPlM+YcP/E0XK+mn5uDfZx0J3sZG+70k3pWpTz8mYz KxqDcNllwiJJUUv6O5qb9Inz8+0yN+SS31ACzGKsjNveJRfkRr2N+hq8q6/xsKkLqEqjbCgnUIkz VXGFlrpl6ek33WVJCasmyJ8BTDfgQnFxRsVoQT40uhscC4YLQqomTl0kLqHMwokkkNKzpzTE4Cz5 XgOQBA8oD+wvyZd8AHdAmAFpQXb87OJne4aXl2wKLL0fgXNHHrkf5T0hhS102lqHsYap85qCzAtB UFRlBJgXIS0IS8cZhnBBsaXLVViQ2D4GN1iXbTx9aC0KNDbz5we1RsBhjKLYdHklgpVwNjQy6FN8 cERe7hifvuyuXklWXGMUkZzIaPFxcRl0323bumH++RaaYU9cvNlqDUXoaqCmCDIybY12GHABMPxA ogIxAinQDJyBOGPqs4vnZU6Z4q8pk9Kb9HHzvXwgGByN1aqPDJyBXu0CTB/yFAhNjVCVK0f39gVv hZBnXsZVOmSgLF1qa6UqR4Xp+NWr7QRLcxOGfi+Lio0YG5+bhi6P7kDrXFPKMtKfY3aoeCVc9D4t +8sAVsYsC05CKOrGUPTEl4LaInkzItJovPLb7sReF9tGaCxyfXV6y6oJYNlMswLTgtmlbuih6sYe mCi9L6XErbxX+QA2rTz77OKpwVWOBfSwKOQXr0tfMgIrm3HuyIRHJszQveHxOSJDoGSH1U2l6f/q iv2mKiy7UFZADC9ARUChttS2vDM1zmAT+8vaKQzddltd1Y4PGvb8fn6TjQnhqWXU5OBsGKAeDWRB DpmwslRaaT80L1THklxdDWCZfRCvoyurMThQWZhDPzI6HIvmzSMsHHC53bb1GogjhgKJs4DCn4M4 RIdLUZkIULp1gw7JJ5zjcLcDbuF3cH6o5+Z5GKEFbJueXXfTjTdVVCzKfia/54SJE7n6cMLA7Wh2 wv4wS8oQfLiz3SYm3VSYdCpLMFkmM4KK1HArazk0H/qgS2eFhXXYypGYz0Hn3wXshN3lAGoopIZN B9qE4JrlovTM8XMfWCUuKC4hnd0ZqSwCCgkqRL/2+OEnWGcPvpKchKa6dOsr+bObglYAwMo2bmEw AaEhPKQaK6YFX4bceXPf0U+COsmwPFgUGXctkwX8GN1Rm23NvVnYGThSInN9n2fy89//cPGI0YMf eaQb+vXQlABMuL83Ki9l6E6AqtDqJqWf13khC0YqKPQtEBdcXhRMhBe8dfhBve2UOtOz7PReZ/xu 1dW7C6vg3TGzSGis84DwaONKo065Lo1hCStLddizABJB5VMwg96n9EVnIv/ik1j5l4noR/qORgaE F5+geN1Q0pQb8iyOGtJCVnjB2/13irdxsARB0W4p0SKi2gsZdsjRlJY9m/5setmzP+p6qM/72c9O 6DsQGduAAbCzYAUFFsYf9lMiE+LOQqXpqN/6hThzt/gLZOaM90qKCi9869LmoNLyH9AuYQjKMt/B QhmVc/72795dU1NYV78Dm4rsQeVN45Pf4BRqdmpoTlmqg9mQagpVhbgU3pg+ftqpRrAgFAkst3S7 c8JozgyxswW5EO6wKbfbhm3be43oFciffYlhFIIA6SxiX4iKVPpUWrThxWmYP1uNQt62CX0j15eg WEd8Kta/9dZbqT+aukbEj+diMVUGKMicsV0Z3jAKCtKdpKinBSH0KxAVxWWchCETlg9a/lq3+Tva BRbW6RUWaCXX5pKVGmGlru5V7rm/Y0dtLagBNgxQFJvwaFZZaoJVOK85Qe78gLvgZjeGRYwLXuJt o5+D8UAkmieoIHWegDqLVFpGbMNLLOW4iGiE3idYFp0XuvOWWzDXJF1VcoSiW0jtuRYXuqAsETOJ STgaTb9sxnNIlrBe1eKTnKEm5wVwbzuFZVN6puTJFocsADEQUVWIjEQhFZba+ja/9C3/Ae0CC15/ pyz4VVVYVFfq6ojK73bsAC476utfffVVPrRrl8jN/PneQpFmlaUmMgfCz+GPB0SFmBoaFnHmnb2Q jDNsW5j15Oj7ddpZlEUdrphcPxYBHqRHgsQtt0B6kDcrLX2RZ4MVCoudt6l64uFp8oLEuJGyFGw3 WLDvRtgd+2cFeCdMlOWHlEULcVjQarhUVlNWGIF4uQprzNopdXawQF5MWfZXE5ZC7IoBZRFUcMXd JvEaQ3N2y1GA+2vwWjdQY7qM9D2PmZ+wZzFl8TTFK8zV1H2EqaGs4ijKQtMpuNzS7cn+T/oNlvQt hACrivDO9SEASuyuLjCSJHc06nFWYuGjyoqDRbNosy/a/ARtmsBu3fBAM54nQOaDQ18grbdurFnn HAsAoZwIO6zHqbRUi1+R8UFtp4WF1TYXhpyy1EBaVFl2UVmEFrDyalVdIWnZD1bQ51NZObKGsDSv LOZTLIPGR4VUFhjcqjooS2rUo1YlZ1GpuL//rNETRiNtHr051PEP3WAEElbcYJ6kmiLrAVCQm8BT WeXnCCS8Y+oiaZDEJv4MtOOGWIgQIPE8TYwK7XLyHIsGn0qCw4soi4tDHX/oXTtlQ6EwFPAsYlmg LAw7QgvuM3zU1Ox+hcoCWnZWfsRcqVnPEpxBtKwZKvMR49C/cq/KzJivAf/oRVz+/K2+3YDLRKmf mLj0xYaRbPLvtQ2bjAYHZcVquKjS07CIsqi0eNQE9mlg9oXNjxtVYjw6VH0afT7w/y6t8CaD4Gap KFJmobJISHJhSCLRNQxLUc752vk3z689nxOtyuwrC6JQ0LMgGRJUNApxu8lX6z4lK7vPQ1qkplAZ n7JYVUWqcIxF5BCgfGqNcj1CWxdHgKOacEu3Wf/5rYl9JXmWVSESiMS4AJcR2GNUP5Qhs0KGCzd+ o2WRod0uNEI0xbyvfNhaJdRtYmqH2Gj5phhgl5qy8E/IK67gPoMQleWC5s1amLsKy4bi8ywp42BF bcwf13i604PFPEvI4FJZkAz5nkWUhWEIW2LtrPx1XQuUhdUVr8oPQ1T3UV3hR2zBLXJn70Z9HThJ KOoy68/T4XSRO+siIuMFUUbtitGDe5hn7ssrPETJuZMFXJlLAhlqXtzMgMxBqmpgjGCVLzoMAwbI odH8fGP9kf+2KYtOGsqcEO7yHqZCPGVxtuUqLEiMB5bTc14LLS38/ZzI4mFAWSCd2ENPM2e6ivpX ceiLWhYqy6uvVsGyABaJQtyFJF5lEUq0vg9VYYXlI1x9WvhR4UNslIu5oa3SI74EtAz+1p9nYdM/ wUVQgZrAotCkiKJgF2Ni05PvuBJccPNINywXICvqXCweaV+d9mS63HvECGzYYLjg8WDG1IsbOaCH gnW5xjtSEZZlMsEssYeYaC2OoAgrlTWeu0UO3fGH3sXjWTZWNlqFWrkxnKMHlIV/CSjgutS5imUW iUO1SIYsG6LB1YPRqa81cSmLLBeSdyoLUKmpKvyorgasFLIFNzfaxupBlZGXk0WXWX3+9+AJ3TxW dP2zT4uLQ8RFmNEBVERczLiItFgOpGJhKwQIBJIpwQXRSgOU/D+4+6Eb3CumUbmGsKi1lQqLyIoa W2UFf1ZeGAI1V2HZUBzKci7KiuWIpZOcD7TUl8oiNTnNnLXMoqaF2RDLLJo67+fxf+ZZbm42Gzqt XsWqtoUf0dpSWWoKf8BGufSNPhh+KhoOSYbLtgk/+t8vDJaQo7srCC1eMhTMipQWewQlPIFFZMXq ePojrW3KoCEq3K7BLV9zU0iOlRkjtuNNIIpcj7+JRTkICzXFyQqrnKzjsuBZg7qmVuQwRra8ptbm 72i2KLc26ur28DqEgLLI+ijSEijgegZXlaXOC0OcChkZVzZUpKhg1lCpKaz7NtwKWAF62Ng0fWN2 sV8fjZUYqQm9Zdtz6+/71kQGHqu0qLjYCNzBXTw+AygJTQPF5XLhoxZcVFE0Lsm4haaEykLnIhj5 5mQAPrEdFw7c6kykvPuhypTFzQSJnJi3NWWx1Jk+9yqsXm1WWXKPR4XleGiCHB2U72pLJJI8QUWV xQq4O2haanENy6LKsvuCRSH8BSEMNa8sRU5Y6Fg+hagAFNytwnUhleXSpUkYKw7nr1usu1dEH6YE 22b9+Z9njUZhFg2Tph0SiXRYaQ6Q6JuPC7QFLQ1ayrUZAt63NgcBhQNr4elLzMvq/wQLi0AKNIXE YAMqLzwFYFkzW4q1kiabv/WjEJ7cutodx11VrvYqrDFrFpbownLzzSFp4bIOLwypZ9ntyv1eMuQX 5Zg6a1GOVTmkzjc3W2eZpMKic82MP0Dmo08/gmWpq/lt+rJpqadz84qKUmaSmdQzp/LX6WKwKEPy 3l4zprz/51l9nZ5QOHBx0ciERBWF9Vx3Q5Mr8uLSGpEVfIE+hh5gGdzCzq1ydIky0CEkxIX6orW8 iP9ewTqbBpJJRPEsDELmWHZW1h1HHGIk4rgWYRkXVVhuvjmU5mOZ6h6r4AIV9bcXLBuCZ9Fyv9RZ oCzMhnZ/QnvLPrAXfy0Gt7kKbm9BxSuuoByHIIRAVPiDwrqRM3u84Y1fnc4FNJcmpYKZtMczKwrs bJfA6yLBaED66mTEIgkvalqMDe+e1P31IvfEjGBovcU8CanhY8iZB464xVCZMUNMi1bgzN4O6LWU ooIhV1IIjkQZK0G0F0FSZfW3cs+uqmpr0YWrXQofXIUFic0qy5EYsIT2d94DWux3YsGatFiDghRw yQoruDw5NTg3BGFB8JIwdKSZfpYcU5a6H4Caj6oQfDQVorIU4jLuXE7vlNzf+NBshNKAGepMdnGm N91rIQEvMfrShv3nCxM9REw+lA11KYREZEJsiEnGQLUu3kQ1yrZOexSnGWAPgchtWqfuhEFp6Xbw Yrj4GAWI4bIhmRGSGj80JZQLYY3ZroCyXIU1Zs3C4lfjIqgJWmsuFTPPwl2hycorcLGsh7DOYrnQ 7/xsaDfrLMyGdu48J7BEKfeH1g3lqLlFvswGFtZuC2tISw14qanBm45qMHMp97TPzOmNEJqZ1Jmz WwIWWDLdAUkbJv/nt6YKEfo6CxHChk4nSviRyokCwVudmfQ87TanPfqtRAzHA4CWUGWfrJSzxrJ0 e/n2pQPKNe+OVBasXtXKCp5LCUGOFptarRdlsUB0LcISs6U2CMu7WCFmysLIQoeLKCSps5RZNAqx RYHCwqLcBXoW7hgQp7LMcQW5H6BoS2/LOERdASu4AS74qT425z5be6ko12fmNxQaMJO6QuyMtJWw 8Fo+dfJ9P7J4I8yEcHGwuPKIo0maoSTxsdxHVUeFCKQAF7qWwDyQuN2lvcrLGYG2s73bC1ABYsqG i5zw3SVBljVoQNolnsUiUcefkNh8US5WGLotCAuExTwL94XWdhZfWayAC2YkcZZsiPOIIiyxYQkp y0gt2lJZEHgk9FBT+I5M3FMWpzB2u3NkzqWUADNvbNyYV9QDhmbFh/lTKsokJ3m2zz/P2gaT6gcb DTpOVfiyy8UNZsi4wKYoKxqroCVGCxIojUPSVudyIfhbLoFj5xxWPkcv+KO5X6YMbS7IM7YqLDsr 64UUC0XXIiyxDO7vw2Foj8uGXKMcsyHrk3MFXFUWVkZkakiOLVaD23w2VElUEIegKx/R6KKLRfyK gEKpAjgxoaGhmRkRnO5JmTTp6NxnVmeWzZjS57553XqZKzGP4mU1qjVSqfeg8eHh4zDIAhr4YEkG p84z1+Y3+LTI3BEERdaM4KIl3MiR/gN2A8l7KGU260Jlqa3dJaGotvYqLEhs1rPESp3/GFIW7Iug Ycg1yrmmSvDhCri41TAEVmqcsuB7YhnckLJUSi0OeHxKRyu2VuMQQlBMYQnqDJRu/7mctTOLNgaC EzKnHl0nZR39ft6fZ2EpM1MbX0CCYqKf0sAjtyI1/A4WT4AGECEtuCUvclemgDxlUdeirNiSlcaw XLAyHG2uaIlODLnBGCTtqbuQDV2LsOTGMC2heSwuT7VfitmQhiEoi3oWZEPazaK9T6FJ5xcr41OW cayrFCIXok2Bvqi3paQwDKmuND0YF9mQVbO7ck7OzKCheYMu+J6uh479eeyUqdI4J2RQGmQaWfDQ VNn7pF9UEVGh7eEtrkGK3CotbiMonUcqF0w0CDWWltL0CzItFHQsgSoLlg2ppmgougoLEptVlssx TEuoJuTBIsoiBdxXZNaZU0NaZamFY4GyaJ+cziPKDvVxKss4BiCaWmTNNVX4yc7WNguJIgRILpCU /bhwagrKN+7cWmTbocyp6J4eXY8mL//RvKnYFcqfJ1RaBBe764mQZkgMRgIIQRGBUdPizTo7PNTa xoKlgmVb1RKVFK/MotpCTcGF17XXJiwxTMukcBjyDa5NOpuwSIuCdlX+zopyMjUkyRD/iuJUlmpO BRXSqLDQL6yoxfX8SnPKIryQkwu84KZ6P972768eiQpNXiA4/fvGg/f02HfizUGrn7PDFUVqtHEp YpAPUIGtfMS0iG1hSFKAfFoChGCbhxiwJFXw+fCLK5HE7Lz2leXj6FW5UMj0lUU65XRqaDdqIcIK lIVhKKAs0s7CxJnF7BquJqptZt3QfipL3UeosQAPQUXCT1wBiFJCRaGcXJB7+3ef3/0KmNlfU31h //nqC9WAF9l2ODh9P+9gj64nJw+a8twG6ZZkqq2seNCYwGzHEURiVwQSjxWNQ66CG+DFglCkw0Xv k58AeW7F9yxY6kzPos7leESXSJtnlOP5Ac3OOudEhyUUMn3PwjgkdRabGqJlkdQZocjmnKWr0pVZ XsSsM/+B5npwa8iJGFrGIXDilKUpQVGbQknh2wUGIfAhkWj/BerK+f0XXtmPbgn+b/bLpbpy5Fpk 27/yXTCZebvP5NVTnp0hmuBtbRnuYdEOBMVFiPFMi/nYSFjctLNvc0srPFa8EBQMRC+KshznNd6u SVgmRYcl1CznYNEWY7/MUlj1KrIhq/aLv0Xq7FaCWJlFlaW5Ci4iD1MguBWQwtqKs7RxWFu1LJQV TliBFTCy/5P9r+De/lcuQFcgL7iWRs/91ed5U40KTcjQ/BuY6Xr0TPZqnGxldkYbVnw7vB3q4mEi 04Xic1yhRZudYoYgfBlgCdJieZDvYMaJW6G04Pp4c0fuxKMULf2aZpUlJSosoZrcZU9ZZGYouMbM UxbOI2pRTpSFLwjLLOxniUtZ2ObEREiqcCzKSS3O7G0TLteTFSqLOdzdF16BsEBacENVuVDN9nG8 Gy8CjQ5OOQUyp3/7/kEwk7x+deaGGdhFzqITqvflWokxXERXsBG7lzx7gUeSoMaJkBBVuphRWRNm Z26DylLtexYoS0tf6Pb4+mZhyYsKy2uhf9sPQ6HMmVND0q2ta8yQDL3KOqytMaOyYBLkHJUlWhgK 1VnY5eRqtqHZoObzZVUVcSoqL+f376aywOCCFFEUAYa8uA8dK0rMOBia3kFDc/ouMHMSFvjZDXKc njoai0B2A2nRqlzYtLjDsKI0dZcui6YsfpmlOpAN7bgKx2k2X+6/fDoqLGGw/wG7UbqinJb7X7Fy PyedpfWJU0MBZbF2Fv4RAZbbvhBly43QikQGIK8KJ5W4Jmu2Xr7MaSj+V5gHaSh6BcEITgXA7AYa uCAqnRclCSqLCUvEjRoaL9s+fdfX7ukx91T+FDAjKbGk1q7VFvfCEhKQl6idNp5n8dJmrzlBiAko S+1VWZDYfJ3lctSqXPiAPu4Lp/MXbtJZanLaKOcWr3JqyK1H1DKLTA2NrOG22s1lQ5g6lHkgpyoy JRSHqtClkJHdYIaG5ROnLAg6jDsOEt5nLApLihMWLlcQheEt3ueEsu3Td8EDz528AHZGq7bWboum FX+3Bc+6aH4UbbVIUFk0bQ5UbwWWgGe5GqtX44ClIZq0hJc4cZ9b+cWkncnrwGVR7lVkzNrNEpwa Us+CqlwlPQtgaS4bcrNBUt9XZRFxiVnrl0xI63EWfaS+sl+v4WuZENHqEhKHidASHRkFxWa0OK2F NwQnMzRopPl3MjPqxNODyIxLtf0JII8Oy6aj0LJpmVeFc4lzqCq3O5gNXY0FiXHAErUJN7wQAZtO NujvhWRIyizWzoL0x2tnYRTSRjlXwBVlkTDUrLJocUVciyHSZOlWk2YBg5ri7l7YXwNPex6GZT8o gUUhGGJs+ZGqTHg4QjxlITTKCg26jMo5vXH2sAWnX33/rq/95ejcyatRBda2bH+Ye4kag2hwM71m J9+oBO6xud9lQ7Xn28OwtvRnNGtwL387mrKEO0C5jXbYs0hvvzc15NaYcR7RnxrSopyGoWaUpUj6 4pADafhx9bjmIhE/j6KKS5slCYJnASmQFoQgKcjhisMlzZFuRXBRRExXfHnBcjqerSvlxXE756yd VOSYOY1U++f7ktevi7bmINoBnoSFyuLlQhqCgoGoJljBvUZhiVrvD1X7L2Nn0kflV/N2fXLKotmQ LF71/C2nZtSzSHddPJ6liJiwusL4E1+Fn65JirReFkRPyxh03kAR1yKYWJFFhCWkLR4ppiyBOMRG P0RSdp3L+m47j3mcVGjyrIlG7MxRv+EqUmVCIlOO5n4jxJLnsGdRZbG5oauxIDGOMBS13h+eIN+D jbP19wMA0q/t1phZMuSWmKmyaO+TOVwoC6SlGWW5xBlmVleC9biYuqK1FWRAWliROHR+dzW6LslF DR2LeBV5U2MbJQL5fJi19eOPF4EYhWSRAt+8CzvAdoqh2firN37zxm/+43QeSnpz01ZmxlxzQGrW zI5oo4wIRkFlqb1GYYna0RKeIOchIC4b8tYj2qSzrXRmb/8ur7dflIWLNKks3My9mWzoEr0Kk2Vz tk3FH7O2TIGkwg9lUfMiWTNi0HkEILwzH/Ici6bNkeUVjUBeHDJf6ywLp80ZhCwS2UnvwoyCgz+c nTQ0Fpz+Y2PeX+45Opf943qKTMTASpCoXsU9iGVDvme5CsdpxlFnuRy13h9eGo+N1Q+IgZc+OZsa EssCZfmdlfvV4LJRzhVwOR8vniUqLME6S45mQVpcabLCb6i42ooV+UkJi/wsrGAfIeZBwomsdVPP Eg2VcBSinmgaJMoimLAKjUvgFGa5K1eycFnyQ7zPQYVG57ZPg5kef9dnS+SaA5wJEmykbAxOnZ8N 7bgqCxLjCENR6/1hH4391LtoGIJcBKOQvzuLlOS09Uk3CYN8SwWXnqVZZclRn+K3ODWVC9GryBSz GFvLhOBna6prML1s8UcMC1iJWV1RgCxjDmRAZIWciGchFAG/ImcyBwMSiZHdnLhfBAebghmchBnY mTNYQunWqRQMDwASRWSqPGVBtf9qrIuPA5Zo9f49YVhwYoPAIk9LsF8bRbnfoYBrZRZRFm/Smc4Q f0ojJQw1U8H9jK3Z2sXfXMqs0iJORaYN/RjEfFkqK5oCWcZshZUo1TjTFcuV8ZGnK7znhCWsK4KK pzMajExj2F2r2zjhqUJTsAYn2Jm/iAVeXJauyhKRA/mRSZUFU86cS4xnQWJuzrvcrnr+8Zy1K3qj C7mlmXKjr28+dY5W74+YxsJ+6mZwtcxivf2FsmpIJob8RjlODcnfrPb2x6csc6SDxZQlJi5eCJKe ODfJrLU44URrthaCEH1kTiiWt/X8Cm0L38TNiq6oVSET8o5f2nKhgMt1oDha0NgkJWsBRqtvO8EM VqxshAmmnekxx0+Xo7kXNPdLNiQdCnHAsrbW2z5WTmg5fv48Com927Azd/OwRKv3h6v9lyEsoiwU WzO4ui6eyVBgww0rs1ijnOwoZ8qyo+kVieckBEl5pek+SulesdKKNj2JW/kEF0Qg+hZpSRBA9E70 OBQMPw4VpyxCjZVYpMjiR55ACPJcCxHhu6wHEl74e2sztinJZzmXioo2nm5UWQn7XevrZ+vTrmZh +dWl2si9hmVv/C/c/HucsXHk22uLMHJbCE4csESp90dsaIazYELK4gq4Uu3npDPikG4op2HoFVMW rbNwM/dmsqFKQNJsIuR7W21HsCyIOZB5WyvYSonfairRJoOCGZDqi7O2WoQTz6KCIu4WfyCqMt45 75IKafwRaBQXoUQ692XRu9XyQ1NAofp+RG7kum9FWZpZkHjpgmx675/GErFJtR6qML9qztq1a3vP jLeRKg5YotT7I+wVj5ySbIh/Y9pVyd5+3fbJrTGTfm1JhmRfU2tnQQ8uPUszyrIzvpqtFuIoJtIR R88i8YdVFvhbK9hqEY7vVmGxbMjdhEr8rrZv5X1ugcZg5AKRUKLKEmlsHStKjEyFSLqIFJD7xFmH baDFyavXxsigRVmgK+JZmoQlxSukck2Wu0ThRXi6+bbjFxCgRja/IDYOWKThJDwiIqbzLPwLCq50 9iad0aFgU0N+5ux5Fhwk05yyjPPmDZup8IumcD6I/St4Q+TBhchI96Qx4goqVrC13oQgM4FpZn8S SECRwKPqokmz6gkTnjAuAXNrFlfcCnd1kj8sb9bQQlLEHHPjkgsZ8RaDNLEgMW/cu41fMUJhp2yE oXHBigHqtT0Nx8f1jh2g4oAlSr0/XO2/7CuLJUNWwEVXpUw6uw03bKUz/shFWSRzRjaEzfybURZU X32D25gXKdlaT5w1JWinLWlhDlQNVNgP5zoRJAopKtGmDm0ayJsT8mYPLQWCvkjU4a9AUOi+GglL IBESV6ub9Jhd8XBpMv8JA2N5kCpLTFiK5kRBxYfHjpWTs1nEw0SNT7ft+facHAaosKmJA5Y5jTmN WA5nsHCHRU9ZZDGYnfEgDQqIQjaNaNkQVw3hSdsNZbn5eNPd/dXNLyKzfFldrfbws3mF7U2vMBRp Yd9SZiOkUZ1ffK2+uSKLTjCba5FcyNJm0xXJhpy+RKZAWl1xFlcCUaDwZh84ZYmZMxsz3D5B2rX5 HuPs1dM5td4ZhDE2SwmCo4f5RPc2/Lo94Q1U44AlSr0/Yjmcg4W2jp7lvPT2y0IQ16IgccitR0RR blw1n0NTlvnNKQvzmyaGiIp8jToWW/nBPmy2UO7/BCFI2/ldtmzKEuFWAh96s8xuHkgiEFGxqSBL guyjgLD4MuNhoqIifxwqL34UiuxwaqLgT0isXbt2R9TVqxt7Nygq/lVzBxLayWHRjc2eF8MCFgcs vRsjGpFy8ZgKK/drAZeTznp6jKwws518AqzINCKr/aoszXmWpmBxAUhWmAAa2hVvLkh6bV1dX6cM LXVumhOTE5MXtS2uhUXijrhaCUTKSegAMl9MPFXhQ/4KZqRE3moyH48Yxta+YKcqiy1gjQZL70+5 EyTOfiIsbgg5dpZys1ojR4e5k8NuPl4ZPls7jgru5cb1/nBv/2XnWWRqSCadbT0iPIspC1fFa+oM jF7RDgV1uPQszSpLPI0rxISLyGQtGfMgaookzbL3u3pby5mbbYjTMKSzQFKv9a2tWhWJPQBABMZK tpIsB6mxjZw0FfJti+9oncw03fWktLyonkWyoV1RVq/OPC/H29rg8ZNGDXFxyCg1fGtufOG2Gvyj 4RASh7I0rveHe/s9WPDXw+cWBVwoAT2LH4Vkw2TtwNV5REkiVFn4azXjWWLBwtKKuVvXvU9lISck hD0Ju1mp1Y5bnTKM0WlrLsVpibkXmzS04q3eiKd1WtIoayZALmsW2WHokTKcyIlccbQg/ug3cNmQ ryx5EbX4ovN79vyEG0Hi8K9Gg3+OnsB4MYrYxALnC184IK9Oi2FpXO+PXLTCw5K0gB0u4Mpe7IEN 5ehwxV5IUS7gWeY3kw1FhyUwwyx3bdLQ0iDUWbg8FXbFfC3LtbGDkLO1gRkhrxdBIxDnDV9Wj6KF W8ueQ0mzkiHv8njApeixmJ5nCVrdJpyK9ymcCeItXt0RcVBv0TmuxvEGNuLCLn+Rg0LjUxOKU42c zW279N9tMSyXG+0rF7lohYfBMwi7RjkJQ+pZvH37A8oif8QMWTo3RGXZhaNbI0fgP9qcuWWjrYYf Lnpn9PmERTis+ICnFcsifsUtEoqRMbtUWTJnF4KoJmZS5J7WbU08IhJmBcV7kGSIq+UT47naxsrS tFdxT0s192bxsqFg0XXjnNoQK0Fq5u+h1jSWm0a2xlyxYjOfIah1sDSq90cqC4RFlUUb5fa/Yiud We13DduuX5sVEVEWPO/874xUWJqeG4oBi3hbaYkLGFtpcZLpZZ1kljYnzgY5e9tMKHKkeGX+apkH 0rItA21AWcS0eHB44YfEaNwhPLrtpJRaQpmzVeVcAt2cuoSVxYcld20t2lr1EmX8hI/Nx25L2CWy UZCC2EQaYh5g2WXcr1sNS6N6f0NEwOQ5jzIvhudRbIFMIzY6bIiepabQRSGnLPAs785vrlNuZ0xt sV5bWUWm2iLt2FzHXC25kCkLvUrUBn6tqPiqom7Fppmt08k6VwwVh0cjXZHwY/mRSooFHcb/UFXF eZb4REVeOS4b8j2L9wqsrUL9HG8y0CvyDzGxeZfYEBpEqCjOxtOa+RaCWqcsjfr7I9pZLuO0JFEW /p0FsiE5H1G3Yg/voSCvD7eqlGyI4bUZZcFTs1ZL/hGDdRXddkVrK1re55TQJ6Ir1Re0JY7m1qHS xNyhtfEHep0CEUgrK5L86MwhP/SVxZX7zbBwVYyDR0RFT2vw5STAT3OiIp/fH8iGdvja/u4eoIJZ fxmY/n9UuQE2j3I5VyO1EaWxQbGJxOa237sQ1DpYGtX7I1NnsKLKAp0mCP7Jq7a7tp41pBvK6VlD 0kAmT4IoSxSDG2GuLl/e+Bmq/t6w6r7YWte6QlpY4kfUwR022tp0oWTNGn50RO91ssJtqC8u0MFC JbFA5LkWT2XU2eqbO6zOHRfkg+KXVzQbaoGy1LCVxdVZdnnKYoKA/UIZiAwaoafhUYADZDD2YGVX 4+G4ATM/oSMWbrroq9LqMNS4vz8iDCEK7cCv7XXg4kVDvPEKuHKKmZT7datKean8bAgeLA5lkX8y b6SV59yCQ0WG7fuiK9qywrZs6XOSqSCvtqKNTlGGJULaC+cikLO4MgUUaMumnKiwSAIdujhcpGUQ FwnMbusvtwu/vAwtgMS9bjiays+G/NWr4ZoJD/PZ8+4ex4yojWoNr0ANolQTY/679WGVa3k21Lje HwELgqmEIaYJ/LPlsnidGvJPMbNsyNtvQzygKMu7oCUeZdF/NKVSXa3NHQoZNhckbdm7dc8VzgZZ IU6ERJcGNZpfDnKik0KaCgWzIWli8XyspUIhUFRNPF3BXbUrmiy7bW2NkEABrkXIyGlDLhvyYfEL tIEymzw4f08DBAZBSkcDpMahg9UYXEUaic27DbsjImLLYWnU3z8/Ulnwa8hzYC24NjXE5v7QaZo6 kaj7mjL288k6txtWPV5l0X+3904nKN7iVJ05FFWBV+H0IeeFtMUpsOiwsaxo5JHAKO8uBGmFn7OG oiMue7Y6f6gk53JlF4iUHDtgilOJ3r7qxom+IC2MQpUfcQ9cNzd0wXsFJNeViyS9jcdtikQgQKmx MU9MrXGJ1I5QCGqdZ2lU729UlEOgMc8irU/exv16ipmbGtJqPwq4eAXdqiEYN+jm/Ppm9pSLoPN0 DuyLTR/qxKHNMouqeMuXKSgWe6ItDLLJZUNE9MTvtLWPtBHB0xFSIJWWcPjxzYqbLLSKLfGwV8Av 2bp7LRIWnDak+4PJrLO/etXN+0gtNiot2oTA+v98iE0wQkFs/DxqT8Orjf9DLVeWRvX+yCX84KFW kkF0GPKP1KaG5Ehnr1EOFlca5dz22nKcG7IhKMuelimLkJP7Gc4H0Dlmm2e2qgr9Ci+8UicroLjV Qb64+CHIDz8mLW4qyORFxcVzL2G7YuBYGLJai9vPVmtJrmobKKm0DBT+kCpdYqYLWP2+Vpn38fUk BjDWvsIWKA485f/AGOVFKIarYBbUeoN7OrKEG7loBZZFDW6wzALLUhU8a8hbFa+b4EotnGM/THk0 WBplQ41WJhSds3SZK1LhVuBeoCxccKjG1qYL3YxQ9DTIGRU/AqllUY2RtcyqKzZD6NtbVRkJOc6y MAJJMU4PbJCyrU9KUFtabnLr3IbJVBZ/9SqnBmt3HWHlbX7z84PhVie4YRZfBJnaRiGodWHo8syI SBjZpsVSim64IcqiBVxt7ueRd67MwlVDqMlZAdcc7q/340yRaGEotPNTrCUvKSN5/ohsP6lLDpky i1lRVqy2En3yMNDo5DIhrdVq10qgyUkrLPYWEYK85NlK/YJOoCvbzg2yDEjEpVUDa8y8bCgMy237 R/66cie6jHEgUZeGPajJRmmrdN0HjTtyEb9Qx422BWRr5oYun/5j6F8/HrmCgBvKq2fRdu1PvG2f zN/u+J1uxc6jGWzSWTygKAv/KKIU5ZpXFiXo9NpK4mEbadjSDp1m1hgUUpaAxXWs2ASzJkHOtkjU kTPtpcrvrQuKkjCHUiGdXHbvfjOCV8BtZeJciTNBxLNop5x/9iqVpdqnDytCd9dU1e/ocgDQ6Ksm jfy8tTfppXRNK57U7IniGlsFy+VwZ2Wjgz8hHV2oqzo1ZGvM0KGgG/dLC66dTBVuZ+HvOLIGYejd KAY3LmUxxSnKGVddg/gjq1M1/1FaXLNtoxBkWZDNMfv5skuadV0QrsSg+OWUxm3ZKjTUE6XGTmW2 nNmvwgXlpKWZEL+X+5m6LZMDS51pcPe7n83/hvQqghiWLnZ16cLwZDZCwQi0NwWD0h43HRSSvZYb XBTDgtNDjRtv+DvI6VvmWWzSWTqfZNEQ91CQAm4dw5BkzixXecqypw3K4iLUpF+7JR4BVjxj27hk qzLiKiu2xCNQX5FYpL6WuFgGHcqChA4XfcgJy3DB4+p8PdHw0+KybeCV41JELxvy/14ZdJyyyPS2 zc7Z9JxuvYUqC1JOzth6TjcAinRt74ky7986Zbm8NhAGcxoZCLEl+B+7qSHfsriN+6WAa+fHuA3l tCo3sobTW21UFvsf5eZUWtukmRT1uJGlOL+24mhh+FRLa75W7knZyFqd1MIG7Yp6W3clqODzegyZ rPmXeWZvLshzKq20LJXSIOeyIf81oLJ4Ycjbh5jnbIi2yEbEenqCJKaYmWGEkhAV6u1vvzB0+bJf 8o+yfl/UcUcNEwW6BNuq0s5HpLRIn5wuBPHPGgp4lj0RVWb5g2rdISkpc8b5xrZxEc4V4FyPU6Bi a7xYD6Wu9tDmFSXGmxby0yDLlw0krdhKPc6V3ALJsj+P2Cp/Wymy4uosPixsZ7qgPxFsMnTKS6Cs hHoV3XlPyDL4KaSqzg1TWV5rtzB0+fJ/zNHAN//j3zTOTGRlUO2OqsBKZ29DOb/OEurXhnqrv63c TYPbPspi/zNaXr8dIdrCICvWWtnWM7ZicbV7xfXCWRN/IOUJ3bVqnOTO3spUYGG8hJWltZqiz5Mp i+qLf1AvY4sfhqxV0UpdhXVV7ChS26hnJdveW7ooVJ1czXwJQ+1mcPEqcDaGTBZGyWKpK5y52LUb Zlz9rUwNvaon3mmDwqtVtuEGa6oy1aJ/a9UsRrefsniWd6cuTo3WkOC520Bx35VWnEsJmhN/3xUl RVyu3bjwxOgjfdkIRl4VrpGatIEXUxbNhvylpmxf2i+qwLY8TUeloUgOv6Vl0SCky81frQvtesK5 iMqRXdodFkwji35FhcW2YNlR+6okQ0ENFKolF+L5iCzSC8/S3O8py552VRaH86VzAXfiRySdBLI3 v8gv3lZlRYauPrRyv6ETzIXUsLgcyKESMRPkcmdvvWrrQhBRCClLAJaAsohdYhw6714D8SzuDB85 l8XqF/oq6Pxcg8DSjmHospy1XVj4aX00ZbE4ROtSJxJIZRGsbatK/D9VWVxNjjmePnHVnP1sd2UJ Wt6gc9Fp5WAYUlurqMh9PwdSCVG74nc5qaS4tYbyfIvVlUKc18ISci2uENcGYdn5QTAb8sui4TCk rtFTFj0p2YJQYCMLpqSQXPm9dlaKsrzWvmFIlKXw1aiwSBySd+BC+ZC92I0W65OjZ3G9/dLaL0/d SA1DzZwYH6uCG8/jRTkRCmNJs586i4aYpvgmRf0tzS1jjqU9XvDxUiEBhDGVk11Sug3MBfkF2zZw In9TL9omYTo3FA0W+S+AaU/cLQ451yjC4p3LIuGZv9eVUBZFBajGUBYPFwZH1vVDVLu1q1ZmUaZV WepEWVo26xwPI+GvScmpdIyY0GiNxeaBrMyPKSsr8rtlHsqIb1os+Bg8XjakNgW/EstNocWGwXyo 1TGIAhzKhvwFiayemMFlPdCvdLmzEzzfyGU5skOOnH+rXoB4UVlubl9lUc+CfqZmlIX6IrzUSwXX Crh2PqJ0VbrefsJSXaet6c334Lacj8bfMfMzIcZvW7FSnGJEIRFozL6KqpjQOFdrlRX1uaLhuthQ aozChd8QpwB5HreN0sKVIH4/S1RYdEWopyzmBOw14LEsOuciW+S8IsqifdANLLi0q2cRYakqjAGL RSBJiiQc8cIFZmZauAmundL7CeVPVg3tr6tFNRptoh2gLB45p3vPATHqXFz4ca6WmRANSWABmZf6 uIxZGZFaqWQ/ei392P6+K8aJ5ijeaBMuTlk0GwrB4lJnr4CLeQ/NhnQbCzMtkmXYolDb9ET1XZSl HSu4ly9rGMI/3pSyGCXKioET6O2XY3pldg+nbWKC9NE96PSTNvSqxl68JXNDLZWd071HUrEtc5Z+ OPlIHtR2Jyveql2x9gS1tV7RVrEJbv5lSuJqcr6ytCUAWR4QUha/YBkIQ+KzVVmko4hOILC+wu2n 5G8YKrMuzrO0p8G1INScslhK78SFDp5hSU8BZyGXRWfUnGWtAltuuO9/w5X3LFFwyl1LYpxtQedK oEQrnopmRW/04u4IPfIQA4052nAZrh0lxTjjShC/gusvdWZPvnoWiYbqWaR4gX0sNCG1g+Ssii79 Z7aCmL+yU5Z2huVTWpbfNaMsgSzaxIVL0LhmUa5CA8tcVFr2vHoFs6EmZadIiLGiCnAwn2KCEiAl ICjUEwNFi3BaX+SV+FvPrPi5UNuVZXdobsjf05bzg14FF0FUyv26QY7ucK5TQjxXm7Tw3MHAKZUS hq6EZ6ljEKr3V6z4L4LJiciHZUUuDImu7AAuDpgwMUSF4ajqSmdDTRKTknPOGRXFwzaeDLNCoyWf 1fAj7yIsIMSbavZTIXEovGqTVfEo40oQX1n81atcdeWyIfyHxMCbZUEY8noVrYpuu57s5t4SuhpH PAsmFdvVs+BcZQ2AzSmLQ8b8SxfBpYvyouISFBg0guJtT13HepZo6Mz87BxzCd/cBlYxKzUWjhwr tlOc1vmtxh9MnK2Q1HZRkZ9QE/IsAViwnlNgkWq/WRZvIlH2sRCx1zMq3U7E/lbEIF2VpT3DkHql WLBEKIpX/vcEhrZFApFFpL93i1kYiBoaXm16F4WWGthWfv348Q9929TEumvD2iJVW19STFnUuTAf CuTK7SUojZRFsyH/Fwx5FhabxbO4qSHXfobU1C/gekdtSCcF6yxQlgPtCUsVyvVg5Y8xlYXsWhAS cQlk0VQXoEJ1EV2J8C6PQlmulmcJYTVexo3/ckFDUbDCD13xoxA7VRCBGISsyoJApBYz4FnaSVLs x9QFlCXQVXmZuyO4MCT/ZVlSJ/sQ66Szt75CKrhIp70yulsVCmVBGGrPuSGRFQhLtNOnFY0aPHOF nm1R7+In0YxGEoZMWjxiqCyPRkmdW9nP0kpRkW8DKONvvJHv43/2L+e9NMiFHy8bUknBu6RA9IhR IGlPd8tCd8CzVAV2Z+FGGl42ZMmQeBZiYYkzX55d0gatG1m4Q3xEWcyzHGi/TrnLl5WV38WABVwU yp9AnScuNLbKil268I5qS2Ri1HBtKItDBcDI+NlDPzhvRTjvRuDgR2pTZFWlVeNcsTZYum03eUHn vvbg4ja4uoILaRQWSee1zIL1w1xsLtvhYyZRlZ6nsLupIdvknCHVGdz2DEOqK2gEjT43VGtLH6st IXq1ps58lacwKK8wEElnn9hcH5lHr2425H4lAkJpiRwPITC5UpwGI7MpWpOztKe9ZoGi81XlK0uo V3HPuz9xBtedfYt+pmAXtE06MwhJFd3LnMUQO8/SrgaXMoY2muiwAN1X9XfciYNOMLi6rVqWDAUu mhf5WZFfc2moa/wMXckKboxY1RiTm250F3zujoewx7222qpncVX9kJS0bxLkPS+7vDpLMAhdvsw+ Q/Ms4akh9irKvD9WEPM1+Z30trrl5jpBJ/OIv1aD256ehXaawhJLWdzLLYToB9irSIeUcXWC0aXR fx8KRY9GCUNXwbM4WABI1AFyOB76ARywRCEQE7i47n3/tt2CEJcNuTpLeIkf292dZ5Gp0Mh2FjvC J9AGHfQsKOBegWyIr7SYjhgtCq59SZTFUH9Vv2fX7urdujBRS/+BJNrlRR08NxRbWaJTchPx0Tdc 2YDQjJPGW82CXLJ8pZRFPUv9nIg+dnYD+UU5nloiqfNuTYbEO9igsNiks3cwi7QrHmn3bMjCSW2X aLDgk/Xa+Pai4OFaVXQSkb/Li/Xwt5JBw7P4WZFLo+uiePG2H9PW0szI4eCI+dlNP7uJb8HBuOQD 44TGUHGgtE/RNqRLsu1T9aRGx0mBlXetKMeszQ5l8TbIYaOczjqz8G+Tzrr5lneYnIShhvY0uDYl GFNZanUfmELhw37NQhET/US1fMIlRpwCsCkjyaEbe5aRKW+09LVu89f7UPys0QhCI7iEkIEtXvYv 34YJ8BWmHUMQf9TxnTkp0f58QsrisiFbuBXce0uW43hnbUg7C1t3kMj9WpSlIer/tzUrEvEyiC9l 5hsrG6Kp3VmjdRZrr9WESP/MdrJi5+RpB5YB1FBiaF1ATWPPMjLqSQZtxqHpSUXCAjXR8dOf/TQ4 9EFBRq81LJmNCaRRcDTU9nYfMf7rvmeRGXKRDFm49ZH4W7fYfBeWm++ypVtu0tm1K3bhgrN2VRYK QUxYtAKH7jhLnPcrH0zwa52Z4RnWpi3qaXZLMVfz50aepXUrzFoNU+7aX7/8xZc9UkKY/PQl/ZD4 KDB+cCIw0cd7rAO3ipiRMubkyLgko4m/nICy2J5+WGMnBdzwGjP/rOTA+bcy/6kGt0t7KosURlhS i6ksgRnEenmaWM6t3eFgedWRUuuCDgy+lVwejfAsIzuSFfS1VH8Ro/rlgJ68dId3wR2+GTMCDNXH Ylakg4mCToNT5dorcHa3pyxMzrQk5w6/lYPkXObsopAsCnUbhrLOAli4erBd54YwN0wViGVwRTVM OnD7avXOF8GKKI7GJBZgRFlwY+69xutciPAsHcjK6d47q1955Yuk5eUvUj+UDKCC8Q1c5I6QwysZ iE+mMZ7JEdsbQ2Nu/MAPwIU4B3xO7ybOrGuxNkZkQ0ILp4ZQwMWKssBJcrJ6FUW54CmVMmH+6yMM Q+1aZ+FB37XwGHEpC/NlK7HsMOfL0q6jyWCpZkVXBKtLYdCLdxwrl369e/fuV16pfoWovPzyz35q ckJKvvGNb/y/r7322je+IVd8RMXmp+RF45InLwKN2t4oxOjuB/K2mxL2CsbOkb3bRz19WCLXIxb6 J/jwqdcO3MAp7NiCU3eyEGVpV4MrW5AxbERPncPK4sAQuann/+hF1l/cbJHBsvvvteyCn6oTSzrO dZC33ZiDYoTAAlz4Ir6sggIyCEjkADkiNKYvDhczvVHqMw6cm3gCmdVfd7+McAdaxFTUzGmH6gB3 Q3aps7dqyG3qR2FxCxKlt5+7nsi+1d4SC3oWUZb2TJ3RW624RIFl7cjKT4JBSFNkgwNM10hRTlnh sK3u6qQxSuQloCy/7hhWcj/DqklhZTd0RZTli2FQ3iMuchUYAEnVR0TmDpEX5SVUj9FqjAkOfmun LKBSWZGiWV1V88fjNheXsJWgwMKGGjfpzH2I3So/YwXVFltgIZ6FrEBYdNb5gy/wcIf2nHWWHXjZ 1hb1f/9GbkrvtedYV/GRcGz4D7psSP3vi0TKanQBZekQVn6TwyeT661EWdSyvHxHFEU5cKCxyHwD cUmsjGVNzvRGFvCUlp9JBNJVP4h1TllkVri+zbRw52O/KOf19ks2JO0s5gcCq4asQ0HnhioxN8Qw 1K7ZELaGp2vpEnkiSICdX23MTcnZ+YkmQeZQgr7Xp6cO/8cXpc1fAhHCkCeCMY4Vbe4PrGWfn7kb C69lO8RCsqKovPxFH4sDr/32QAMuRw40/JbXGI0khi5G9MWPSE5mKDVWjbnpppekr0A9i2Rdpix1 hVWIDG11Lv9gygJtcb39wT0UvLWrsh6Ry82ltx/HpfirQrtw/9x2rbMAFu2XbfZlKbq0ds7OQtc1 56VIQaHZUV9TKNmRq+h6ytIRrJyewzySZg+sQFm+qJbliy8bDwca/tBwpAFvR7w33AU3B34bJub/ pekVz+sqMRqV/EFk7vCVZTegNFqk36Suatf5Nhaq92CJnoYhb9I5uFuonrThd1VKb7+GId1DAX+2 tdxvuZ2V5R+4IXOMMBRJ0Om8lJk5O6u1+B/wL/ahNFn6rOzwlKU9k8pYVKfUGCvmWTxlISyOEdLh D2MH52uAmNdeM5V5D0YYNscyKEuRWPhl7Zc3Ol5zyrLrFagXhUX9LRcDYylVGwMRF/9qGJIFCjLp LFvp6Koht5MPLQsXgvjrQLSpkp6l9gooC6UlHmXxXqTTG4su9Z6DOr8zMi4hclm1lx65bKh3G//M mlU9fEFvvEB85kxZ4G9dmeXl90RSjBH/noOGn8FXgJcDBxpUY+B/YV9ewttLdzDvJjFe/c4czWtO WRjsNHWGxYTDxU5d9buO+9vwx/O/b/Q1XHUVzoZwiKjNI7LMonEI6mJrzNj75DY5l45QyYbaXVkA CxvxW/orQWQuzalGWDLra5KiCZO7Us/SEazk1B4/LtVMMbiaOTvPcgCkaOyJMVxgMoUBK5ItSVlG EiRJlJQauWKIOqDKUkVX5OytJkP1VQS3ba4FKzqtRQEtlYECrmt9AiWUc2nut9Yn2YlYlw1JV6go S5f2bH7Cvt3Y7h24tBQW/frTRb1zzn0SNjKesCAMkZW1Ubara92/Fvu75nzwAWFhPyq3iyEt+EuH Z8Ef/csBTLocOdIl4hKOS+SKpLjcWsozLPpaXu3fHpFtA+uUFVMWTZ2pLG2NQzhGSGGRRFib+4NT Q9r7hHlEFnC9FlzrkxNWfv0Bd/9vV88CWFqnLIEXLrcopfe585xu9ByLORd2yuX8qr3JaPzzrjuC DZQ+IC0IQwjgiAeqLJIOfWCaAkw+wFvtEVw+0MsRPICLH5HISsMfIhwvRIbVXlEa0KPzBUfoL3e/ bKxomUUcCzwF/iPHG+1B3aKngYvFrc7iTTpbmYXJlkucA1NDbqc2rrCUrq329yw8Vw3S8miLw1DE r/7G6Y0pvedQZNT6SiCisuQ06utp0ZMW1xfnkIYPJBCJaQEtjEM6NURcCg9QUUDHEYjBB7jXBfe7 gBRig9sgLgTnD7AwjYDhLEFg4EcdR+VWknMt9uMfRS5EVuBZdvnHwcT1O0R8EQ63a3Dd/TqRiMPP tZ9Fdji3bav9cr9Ylv2yTY15FsDSzsoih/DR4rbmN2r8Pbkpl9ae+4ROhnOLtYUjO4KVFMaZLmDl OF6jeksNRFmqJQy9/MWdL3/xCMCQ+XU3VyybuREZMgTJCakLHI4kSM7vmosJwbJjF340frYUWb74 yhelfsvNU1gyw7ZfbXpGUfxSZZHVtTrprMqCZYHcqtL2UHDVfq+3X458krVxCkt7ehacvSd1uXaC hU/QGxvzUlCSYcNUXU7wVOs2PXuxv/n0v0A3RFpqxeNKXU5nEiUQkRUOqAgFxV3kjg1KTpcPuiAi eRqDePQH5khRppPgZ9577Y4d9TKXQF6kessoxO0wJHE+DuvbJqvGgzO9dUNicXc7ZXETiVohtS3O 6+RQLzG45m8NlsDsnH+3lZ1yhAWHBjc82t6v5GmIzJycdphSa/Y/Nu691w4ILnAtpAWuJSIfUl52 vlzHKNR4qNgwJOGHRBgYURiUev/g12GYJx1HaAvoClSMrIiymLAc/6BNfydgRcIQlcWyIduKXTb1 C6+Kd5vgWgeupyzYnb3djpDhy4DTXDUQNfuaXKtfkIuZnz+8hrgBt4oNnqktTlqkhktHAVBeFHX5 orO2qiqqMtporl4G/sVTF0u4efMeiGFhDwWb114DKeKEVFeYNptl0RPSTVg+aNMfCndEEmWRLUDQ r61llmBRDsrCzFkTQJZZWOzXrSqlznIFPIuYln9os8G9eihNAizv/fY1aAv8KqWlqr6qijOJtLjm cXfyVX0RyGAUHocGEREvDHn3kRpJpBKJCXsYEgNaXntPSFFUzK9oJ4vmQs7e1n7wwZE2wcIwxB4Q 2A9v4363oZzfgqt1Fikteeffcvs8yYaO88yiI+3qWdS0dGJl+fiOO+grfos//Q8+0JRIm4HMtdDi QlpUBOSVlgFT4QUl9S4wu8ilJVWiGfZCktZ8aV4eKpRv5c/Sn2izzViELKxIKZ7CQuCOtC0MOWVh 11t40lnbKiXndBtucGrIOhQ8z3LuA54s0q51FjlOD2cB/8PVk4Y2/ssLUZX/BouufEnhcZEQ7aqq ksIc/+B1LhGvKl9cRiN5kdXyYhynmigqlBpp8cPdQHrU8IfX/vBBIb6V34N3pD+SXmkY0gjkdIUN j7uOgxXKUptqBmwbQRjSDly3HtHbtFr37cdgEHJRSKcR/VMqd+DYuyuiLHs6r2f5FzZECi1QgIc0 EukMkV9sES+KV1olQV92PqZX/CQbDYIzAiItDUdqSYkbAcw8VJAHma5IIwsL/eSO001tmhADLOpZ ZAF2aHtt3eE8WMHVlc67xbN41X54FhxD0y6p88yPa2ox/dDAc+vFtXBtWw1WPLXx77zjv/29n0k3 Ngv0mkCTlj9xY1g0teyutvyZKbTGDnvJIQ7wvEqCd8cHQz5FrBQnSgkf0GxZhMUr8vsxiKzguEPR lYYjbXoq2JGm2RC3ePZ7+92RIDbrzylFNzVk+22gp17XquzCmc9tDkMp445gL0Q5zbUBsKhp2cMJ qcJPsSVu3fk5nYqYO7BwjLi89t57r/3WaDkOj6u2hdUWLbfwNQ6iovQAFMuTzNaojAg1pkMvCmQK DB8VJdKL6Aort1K6pay4GNRw4F/bARa+6rAsstJZN5TTAu7v3OG30ijHc1moLLIeEfNIsuEGsiGc QnNbmwzuxw3zb5ZTxrvUF9Yg1uK+SgsDrx49VPNJYWG1f0xSm37nDvhmdjiSFvG57/GPmqVcjxb2 KmgTlNXQ5HV3KqMvv12IC9khHaI25nRMUexrnaRIjV8bb9XbMmnG3OIHkje99lrbehTYRC+ehX1y stL5vO37pCfJ6eQQd9cOK4vbqhKw7BBlaXXDdk4Dz9C77d36wk9e+QRwfPIJYdkjtOABPsQrbC+E 9+o2tu90ACf8J07r0lT0m4jNfQ02F7U5pkS2TzxbtyEu2o+rUzkiFO61VwlRJbEw5GU7Xo7sdMZN BSkxMnsoDWxg5U9/cmnQkSOs8Wa06QlwYUiO8pRsSBavut4naZNjMiQFXOl9cpuEcRm91lnaEobO ywl3XURQ8DuClFd2f4ITs4SVf+BvTV7kCqwUvlJY2LaJ0zY9WXF/c5H22yst39BIJNrypyqGIj6H Ki5+NFJgNPOVO5LfBD72Sm7KlF47R8w1jiJUDhUW+dFIWSWyQpesLQ7Xxf0rRPvCgGfRqaH92tsv p7LIekQr9rtDKvF76ia4clg5xw6eWdS6MDSOqMyvBymf7MYF16/UAAuGJLEveAQP4RNKi/BS0xlw wfIvo4W4wLjIFHQgFKlzkUloTizipXYKo0lwkBYhwjlYJcWLU/Z9GtIsZWYI0qOWOR9EVFRW0JfZ NuPHFN71s2juvF/L/Zh7CqyLt3O1datKehaeBik7yjllaUVRrvfvgcqeegkzQgOhobIgF0cgYhgi KdQUvhEjwaWwpiPaZ9v0N0hYiAtCEZeSSQ4t2kKXq9pSw6wIBgNXrv5vBka40TDkEHEAGSmYVPZM jUuBdJWQ6+YXXRG7IlmQNmW+9FKbanKXnWfxpoaMFd1DQVtaa/XcwdCGcph0dps97KKy1LZ8IvG8 qQpoEO3AX5rpi8ACafk9PYuIjSqLF42ueXHRlaUmLvC5xEWmFSkubIXSWATjwuk+TxcoMi8H0IlA QgGh9DhC3HeyG8FQ4UZMRIUZs7HyB6LCNsyH2vQXcLlLl78XZZGNESV11iNBdON+77wnr5PU7+13 XZWSOs9veZ2FB8N3KTRVEVEhLqIvqAhr9kx4jBIwIxJT8wn+e68W7mzbr32lv3uZwiLigqxIxOU9 iMtDDEUUF8xBi/3j4mcMeeK108W1WluqZEmTfAYWxShRg2IuhZg4UbH2lSq2l7jqygGEwddegq78 tG3+1lMWZkPhM50jLAsruHqImTQoyGl+qiatUxawclstfh5FQ7WDWDDYvPIJGmSYSL/7rtiUkLJA vBmI6j+9tmmZhj2RnbgwKwIvL/k+F+JiaZGzurJgnrQEEmqfB8uxgw/o12rosdo+MyBbqcpTt6Er mJ08ggnp9xCA8O9juciktv2ROM/iOnD1PFNtrtKpIV1wHtgE18r9XlslDW6LlQUxCKywRCW0+Fe8 y8kmnkDhlIUcic8lOXYYUdU1nRVtlL3WfXG5A7Rg5c9vmRbRuZAWm8PnUg1PYcTyEhgBwSfCf4g5 FL9KJn9kaGVfsmV53RCBBBXMYBortpbxZz9t08wQd+TSOkuUM539Qx6QFPnbmnrnI1oLLpXl3fkt 9CwpXBBQLweWUVsgJwqN2liAJHFoPj0LtESkR+/r8eAMkIVtW9bQtr+xZr97hW23rs7lZzcxiWZa 9J7Ucz1cdNGeuBf8ljITgBdfQxIAkQWMssCd5AghfMdXiNXRECYVOCl4yLboRAWtnELKH9gTxUUA XIV2000PNPvfbvoLuK0Ad8wkLuGTV82y6EoQb8tkV8BlLmRbU+2Yj5NFWuhZEIRQy3+VrNQIIFJn 0XwHygJYJBDx6WPtxWACVe6QMwjeuTb+6lf221NuDIuLxCLUXIQWVRfxLrazsLzg8rKbXph0KA7B YV/AZ0YuTJSdprBiqwHIy5d9VG66qa3rdblRLLyHN4u4/xV3rDazIZt01o373fmIOuksGyabZ8Gs TguVBTjU8oeqthCXYJ0FC5GUFk9ZkEDzCyRCFgJjbp8R7QTFKwtAi376XctC4oIsWmMRfS7GQ340 kkVFFBjMpAg0IjMGg9zoUO2JGHy5NPwgycKqapkKUlY0XeZqet0JqI25EMIQGiek+YlrUYPnI2pR zqvJBSYS3Upn1/y0C7X52z5oWZ0FpThgqtoitpkwaGpMg8JinAQetb2aUeskEXsEhZWGaFsqN345 TxfN7J2T81lO75lFbZqebxEo8sVvLNRTYlwSLfV/jUXkRWg5jpfX1xcNSeJhYg1+Gl/ANx5NyHdZ cCik1O/6E3+mdq5wDlPWuNqmUTfeuKLlv0P4O/i007N4iTP3UGABV09etWFRyD/SWaKQlVZ2MQy1 UFkQhXgOg0xOkhYaXebGLKqImWUObaA4Vj7R456NFZymGsfvnrv2Mzf+r88+y1k7Ker+rnH8oFZ9 SaqEIh8Xo8XhIsFIZ4zU7nJOWgKzyoxc3K3el5IkvkL+bORPRwZ8irbZeqigCih7jXn7i+E4gDZ1 9vMJ4GEIVmfRZUMShmxqSKr9bm4IE4l2PqJrZ7E4BGXZM9/tXRyuzcXs7sceHY8aLSIuNYWfSF4E 78I3SaKpKYRH8mr39DBFE11B30uzL+Dp3h4qgTs5vS8VtakVtdl/1/uC3EVkJaQuIi7qXR5y8gJ9 CQiM8mB/Qx4VPhwgxBhRTIwUJc+WGiFf5gJ6F4BE3dosLJe5RE88i60akjOdpSYnL4trlAtOOlu3 tnWzsM7ScmW57WbukwBtoXERcVF1ob64iwQfwiMH2siz96nZlS4N3N6smRftNzOjoeIeY1zqgDWs R+FcnLhoRVdmF8W7iHnRaCRL0URgEE9oejE+wnOi9xwdLP1K+VfCjgwRFE4tU1PYimClFScrunsY x/D4GY/1lVyiJ81PXjKE1+YjK7Po7iwuG3LlfqxH5Ewip6lFR+pboSx/vHk+FqhyB1PplHF/PxKF SYhddtdAUjzNlcoPZaUL96t6t5kwVJTTFCv6uZy1vVP8Y4vb/mxG+Qn/Jy0iFklNl0Vd8y4+L8iP RGFUZRQbu+vf6CelBibzhLgoKB/UQqlkypBmhbuK2QaXgsr42f+n7b8eV43zdMZoG8qFdvJ5VdbU 0VgJKm6rSqngIgy10LOk3IZvMloEF1UXJzESluhR/OAsxpa9WBqC9rw7v8kabsCsNMtMTu9JVzIu 5Q238xBDVpcbfzEYSSatk0YqMOzWlYssH+EvHWV4kAgosjqaq06ksiJmhb5W90BVVjLagZXLnCeU k0nQ98Zy/ysX7DRNMbjeLmFukxFWRdx6RGuUq9yFSZyWepbL50mLhiKNRUFcIgO1pkCGirCCZH1P E9Pt0c1K09QwLrWxwhnrb7fHwz4uurWkTQFIMJLKC1XBRSRlBokNtUPFw13sjpGldpYXHb9lbV+9 yk91Q0slZfzs9ilg0r8iDPHMO++sod2IkVWYR1RWsBBEyizYRDm0asgaFKAsPDqvhQb38uU/aoOT +Fz8H8gC2qsaY8L8R/yTqoqTlfnzY5f7Q2YFstGbuXN8Iyend0r7PLFhcHoEna51RukMo7oXLdVh fPCQ5Ug+D1HvsZYvlASWnslCecgKdkENRaBlbZwS8n4VKoud69m4gMvjxMSyeC0K4Q3ldPPzesKy q8UtCkoLN0sQ66LyQmI4YalpIVZHKSc4XFM3PPZZGRdTBUJmpbeeXnDp0qTea+Ml5oqk2H9ZKUbX n1/knvwOFzTT+RFJglLt8SO1D8k6RK7hgH7oCe4BGTG67AY+BW+NVQVmpb1QQeqMF4Hnsbh9n1DB 1U1wuQ5E3K0tMbN2Fn/jflftF4P7bouV5fLlGutwMlwCwEQEaZyWKKhgDw51KxjjYiW/IbOy1qHi bnu3BBmk2G1rFgqrS95KJtFuOto2OjazK/KCBa/OwoRJoH6oe40cFKT3pFRrU8ueqNhe7Qvb1hsX /g1EObBVrFfAhYNFzsZGOQh/vZ28qitBAr39ctiQK/ezp60VsFxey5dduvhlt0FZg8fu8N9hVYHI Sf0OzjfI4xSVRwUVftO7I2O8iiGzkjMpkhVfZOJXmXYs/eal3RRIpF00CugLAxIzaheUGtPx2h/w eXJle8wJY/Ap2oRAqxIwKw+fbV8TpvshYct728lHy4RsUAh4Fm8akYtXpVGH/QnO4NbjJfxJa2C5 fPlT12xr4cjb1Ca0BYVstt0gpRWVlVg7i4fNSgxUWhyX2rX0O4nmxSu8+O5FO6S4k7+8/K/9Fjd/ +C2l5rfkQ9utlQy9o/ex4yk4kbNF9DQIH5XhK9qXFFZwJdDs2LHf27hfD4u3opw701kcrvYCco0Z OnDdqiF4Fr6GLfcsonC5x6XLSVr5YV90G3YxMXaSlNgUA0VJua021pkFQbOCMm08oyXmF/NL7VH6 zR02u3E0cumRAiMkgA43HCf8nI2XuAMht6g0TqSu75EyO+OKJHbcolzUpdDWrlJYUJTTVUPW2q9b VVonoHQAytSQhSHC0qowJLgU1Uhc4c9wyGA3KoQcXjjcZyT+zL/teOSRoC6shsxKfKi0WGSkkNf2 FDsvDbx45sW5F0mnJUHS04cATQAO3ZHSzgnRG2Q93o7+/hEzD2Rdscq0CYtscuivdLYOXN1QDsz4 jXJuDwWsdXXHf7ZFWURd1tYSF9nAxw0w4lGiRkVQaTi/NoaxDZmVRr62/UWmraXfvKzhrOzaiUF2 qAcMhzsET86sUjrs7CFpYSJNRghPVtThzjp7KGNFSruHnqDFFe2wXe1fRblNPAvnHvxV8XLinW6K xihkU0Ny8L2mztweo3Wexf1PinK+vUfsy7s/2YNEPDDeBSiqKfNrz6+NVQJpkVlpkpyWZNhIsS+1 YRb7PyZlsFhnvHjHwCgA4ZMT3YkgPhwSctxJMj8b/vGKdk3cYlQX3b7TQkztqzitxyYSpcLhTSTa tk+kRXuf2KNgpZV6ikArPYv/vzo9c864WqGCdNgQSJgy1Y/LmRk7jQ2ZlWZ8bTwic6klGXab4tL/ mZn28E0R+mJHrkYc46CWJHTQ0M8e/teM62CjrqiaRFEWbcvGdT13GNQyi+dZkEKjGk9pYYeFnQji OnArf71LPEur1zoH/zc4SWhO5fkq7LuhRqahtup85ZzeTf/5Bs1KnL42LmIoMvFn2Cz9trK7Km9F xvCfhgOSxaWAeviPPPTQwowVk/I6qMsiAhZ3JIIUOVh5R7yxbchcBVdK8XaKmdtQzuacq+u68GSR NitLa+dEQ2alZb42bmTimyqQWezWd1elpGYtHP4Qa2lyhHPkuOOhB6ZdtyLlimQ58T73Iin+8Ty2 C7VU3b09FDgHKqvig56FUWjnizW7uiDnRRy6SrCEzEqrfG2cxMQ/vcR8qS2l37yUlBVZHB9P+xjX 4KOoI/xIPMD4qLhAZIaXeye4PrnAKQ+60JlnE1XvL9zR5VHs/MYc9yrB0u5mpf3Mr1iZDuiuiudF bq+vMatiAhM8E8E/diXYgYuECb10CFMAhZh0wXbuDEPu+O042yrb5b+fF3AUsUr7cQlHS76oBWU8 Kf1e8e6qdnkq4/shwWzIVXOJjEYnTtbIu8AEqdHNK6X+roP1M55Z1PFhKDfQYNuevjYuclqUYTMu pbTnlGR8L237f1VYWVwIElwABSmR422jjgaKC8vxEJeOVpYr7WvjQqZFGXabUuz2f+Fb8xPDnsVz uxaPCAqVRKdquC66ETgQFipLx8Lyq0uBBOXK+dq4iGlRhi1x6Up0V7XmtW/x9wSzoXBi5Oq6qjFB VnyhoWeRiZwOheU3M6+GWWmanBbGpTak2C1+idvvGxorS6D+L7xAW9jJFpSWAC1qXzpUWVKuPVS8 bry4M2yY384Xl7y5IZtRtPijdX7/NGQ9Qlv1hePvPRMD4wJcOk5ZWtGHEFc0ab8vaqHIXIWFta3V Gkt0CqtxLrJfnZMynZdH0+VqLPJ5CXheiUUd5Fny/OWon312Beq17YZMCzLsz9q1u6q1IMTzfSoh 6MKtrNxvqbNXnfNpETcjDtdMbtjpNnT5hw6BJZgtf3aVfW1cWLVMZNqpuyqel711XyOA1GkpTc5c Fy60rmIfaDRS66J5EVvZwnlRR4ShuPpr43oNO/iLWrAUxXVXXZulX6FCz72rrLZAhL6W3e5UZL+O q3GJybSoSxiXR6+4soSy5Q6r17YfVi3LsK/N0q/wYZ0pO6Xjtha9/lh15tOiyiKlXG20t/5YI0as 7hVXlpQc5g+2QvlaNitN49WyMp6Ufq9CK0KsICWwuAkdOdahXpeOOZkJpERIiCAsmkT/vVMXTYuu sLIEs+Vr2tfGpUQtMb/t1PXbOo8S+V0ShhSPSlUWnJEto84MTD3mDl91GTUFhsyIZXFXpOVKhqHQ EsPO4GvjRCb+JZIsylyhhbUtwUiUJeRZJDPCqFGv+ypJ2lmns4maUduZ1YqLGt1Hq8LTzfZRWEKT WvIf87421LXfCc1KM10PcZfxbI+Q1ndXterZD32TEGHZUJ1kQ0ZO5W6t/tuhz2zzD0wAaBCSKp3G oajKkhLuM2wNLKFs+fOGSmuWomjpty3dVa2HRhOgGnpanqaOD3abKmiRzjiStNq7dPkdlo286lgR YKLBErnMtuWw/GpSeHuvuPS9k35Ri51Mx3dXWUGlbvfuOkucHR6aDrmgJDrjcMFqV4Ymqf3HVJaR jZZktxSWN0L7fHXeFKgl9LYow+7o0q+r8WtxX9418DAbCuhMtZMVGlz9ip1ScrFI1EhZGrNyuYWw hFKgz42vjYucFmbYHVX6dUVbDxVYWupGdb2W41xutNubC0BybXWZmi5udrFLF6dHzueOjNK00SJY QinQ59WstKv5vfKz2E5Z/OI+1oLgcAld51y741UvkbZaLpTFgVFts0VQl8g6SzRWWqIsCVRaY36v 9J6KTll0Nij4bnPQgaBkj3hqU+2l0ZHK8uuoW8jErSzh3QNHvvRSXNr9Of6ilprfNi6sbbKCay43 hIoztPWkZRyrcqY13rwjkmsYFq3QdXEKpEIUfbuhOGGJ3D3wHDYM4PgcwxDfr9bCOez27666lDNn J5PkCFUxVPj4rsLdhWZgTFp2mWeRGq/NRgc9S3RduRxfGDo9yZ8Esqkg7C1hvCSIwd54LSvjEZlW L6xtLDGni1Iu5eysio2LqYrmS4xXWopBviQbexGXUJ0l1kklcShLtF2xR/7gCLeZ8HhJiEzLtlNs /9Lv6Y25M3N2fgKR8UXFu2fxybJrK+siNOkUgLREBZQl5tGozcMSypa9etyczz47N+4HD2HPtBAy 8Wn35/mrWpRht3/pN/fS2jk6KxRmxsdFP1OHfEm+SKahoSw+LLGP0W0OlqY2UAcwQsw3KDJ+VEoY GdmzNe7NHlRl2nFh7ek8hKVKFHSjKItFIl2xKLqiVV0flt6xDyppDpa4fuWR435w/BuiMQkjE1DN lpvfdlxY+38YlirPF0qLi/fu8PHtiwYiH5beTexR0gws2DHz3Mj4drcYOe7b//JeIipFhthWmN+1 7bGnovng3JlrPztXExmE1PGGFopYGFrb1H42zcBSLccdV4+rjJeYygtGTEJjgti0WGTas/R7Ojfl 0tpzkl9HNTKMRRaG1jbZaNwMLOf8c1IuVMdBzJzPeAExv43QmISRYbrU0gz7s/ZbWPsrILP2XHUN Ki7BqMR4JLojypLTdFN6M7DMiThbpyYeYoALRuWFf/0tNnPkW6Ii0xYn06a9qyKrMiAm5xwbXzQy mXcxz5LTzE54zcCyttFBTHigpnrnSOGh2TGnchwKMgkj07hW0KIM28uX2mdbw9O5RTPXnqux82WM GyhLTnNbkDQDS+9osMhjIOZcHMQwKvkFmYSRCWHT8gy79R11kd/5hh+WJB+qq4y1Sbr/nc3AMjMm LI6YyriIsYJMQmOi1CNbYH4v9W4/WvQnYS/SnHOfQF1ebZ6V5uaGitzZgE1AU9eCZEkKMmEj83ku 58b/u8VjfnNSxsU+/asNFDEs5eTEcS5lM8qS27Sy+J+tq4k/vR534XiiIBOFo4ea9oA5lwpjHb3S BlJa8q3NwHI6Xlj06+JLlphej4xSkPkrT69f+pcmYZmUgyf46m5Q1Vy5H6nWyJorQAyN72dzPGIC 09fxS/fn6ytfeukHTcFyaRzLo63cL7wl8tHE1zYHi3zrRuzI/klLiKmPN1lKFGSMeP61XIgNS07v Qh4SfK6dXvVW/pi4YDFi1s453xJiEJX274wnWVJifnAEzvevdfaap569NC4mLL0ZgjDWtvJVbqdv ix+W1mlM/DNLCEso4VmHzF9ZQYanWr10R8wZ/kkyRYfRnidxtgKgFsIi/8JpRCX3349TauJMlrwO mb+qgozIyh0vBXdbC2oMQ5COuqu8n1BrYGktMfEmS3imtEPmr2NmScz9HZNi6craz7w/yJ2tUIP2 /JZWw9IhxDQuyHzu0muepYc2w8A+9mHn0ptZkI2c9nzlW/Gz2gaLElPU0qgUd7IULsj409efn6SZ qgJWYoWgz3rXBQJ9rK77VrzurfqWdoCllcTIXGTzyVKgIPM5bJHRXylmCMoJt4hc7d3J2gsWj5iA asZlfgtBTBxteLS+0lMV4WM6dVjSUuQdMUPQ2vCTeb5VctCO39SusMj/61eISi0lJs5kyUp4smTp c1CRMbsSM2POcVmQ/dVdkVnElrDU/rA4Yj5rKTEtSJa0IBOxnqCziYwWV3rHYiUiBAGYdu9PaAko /NorBIunMTvjikWBL4pvLtIryPy0sxoZKa68dEdMZ5vT+G/t6s4iXmFYhJg3iibNaQUx8TZuBgsy nansq27lp02FoMhWoqs8i9gRsAgxv2klMfE0bkoJDwUZ/KF2mtXXzRVXPotslKf0XuVZxA6DpfUa w2QprsZNLkBBT1WnyJaaK65Et3tXeRaxY2FRO1XE3SFaOOr2x9GGF1GQuYazJa3ZvhR7ZXBEFqTP Vv1VtyxX1ODGNtutIiauxk1bsoSCjJRGg6uvr5FsyWQlZnHls5HR/5Tq2mcdSEszoODXX8lsqJn/ F4kJFrPjkpv4kiXZl+DCvz7EoHSNGRkt78eWlZjz+Vd7FvFqhKEIgvKwOURclAS/iKvcml3gpl+A gozzMYGlkVdvbkkz5iZYiRqC+MvntEUT2ud7r6Ky+L8ANKayFRoTzyq3OYxLLOHxNbrqGw+xDIf3 2CEosLY88k/oas8iXgPK4hNDjYn5ZxVLfOKai1SNyWGHjCVLV2nnIZZWQGxMZ9tkS9nVnkW8pmAR bLgBTYuJKYwnWQIuEJmcbyO9vkpGRkiFX4kZQEc28ZvXXOWOSnl1rokwFBFRc1ujMS2Yi8wJFGQ6 zshozTZ258pnTXm35vY3aB9P0txPuRZhcRpzroULlhCr4kyWqDE52HWosZG5Yvl1c8WVpkJQ9dUv sVyzyuIDjk2urhwxYmSkIKM9MlfSyFhx5SXduibKOBfb4NetvfoVFn1JrlllaTsx8c5Ffpbzr7+9 g3/4Vy5baq640lQI2hnHivXm4kc7fb4TwGJRqXUaE9fMkmhMDjtkrozINFdcGRl7YU1h7/9op1e6 HX5MZ4FFicGuaC33MYUX4mrcZLpEYiQktWfZV4srTWRB52JnQeeugYTZp6xTwdIGYlqSLOU8hIKM 05g2LynQ4koT04ax51VrYm923Q460fIf0flgccS0dHMH1vXiTJYkLB1/TzdPbJvIaHHlpTtiF1di rx+f09weby1/udv2HZ0Ulo4iJgcdMm0xMlZceSlmS07sLOj8tVCGC8PVmWFpGzHxJkswMuzCa1W2 BE251GTnSuwQdG2U4T5nsBgxLdxARuea4txxU6eWsGSphSIjbgUjZnEldiS9Vspwn0dY5HfamNLi DWRIDDabj/d4AuTX5nvjMTLMgvh1Me1KzJn2uqZ3RW+b8WjDd3f6MBTxu7d4kyrVmLgaN+1Vz8kR vbCyb8xsCV9xqanOlc9ihqBrqAz3uVUW/xcjMS3cQEbDUhytvk4nctghEztb0uIKQlCsETMEFV71 tWQxtefzpiz+L9qKLYfQFd2i9Bq76susdeO5JetcaUUIurbKcH8FytJGYtT6xnk8Acu+Og0ZrPsi C2qqcyXm0t6aa6AfLrap+fwqS7sQE+cqN2ZLmvoERablIeiaK8P9VSlLgJgWbzmk1rcw/h03Qcxa t8itKV2JlQVdg2W4v1JY5Ndu+SZVjpiWWF9kS01MG8YMQddiGe6vGRaPmBZvB8L0uiXJUotD0Lhr pBuuqTLMX4Nnifb7Y8uhlm8g08K5yGjAxAhBdU0eZNmGOlq7futfKyzyJLZmkyqbJ4hna7MosMSo /lReU20rf4V1lnj/pn7Vmu1AWJFpycySchOjEFdz7Zbh/uo9SzSKWrWBjM1FxrMliLASY63HyM4h K3ja/qrDUAQ2rdqkyuYi4whL0UPQtV2GSyhLkwHqjdZsByJzkU0nSzFC0JxrZZlHPFE7oSxRn6XW EhOzcTN6CKq+9rrhEqlzPH82jb+mHYmJHoKu/TJcIgy1CB1uBxJrD4cmHg8lS9FDUGcowyVgaREs 8sWt2kDGS5aiwlbX++qed9jyJyGRDbXgOWvVJlWxxKeTlOESytICQBp9KY7LbvkGMo2I6TRluAQs bYFFvrdVG8gEiOk8ZbgELG2GRYlprcZ0pjJcApb2gcWIafFS/U5VhkvA0o6wtJiYTlaGS8DS3rC0 gJhrZhOnVj0HiXJ/q562GN/UzAYyOztBN1xTT0cClvaERTUmxpZD19QmTq36rROwtOppa/abGhPT KctwCc/S7CvdXl8AYty00LW2iVOrfsWEsrTqaWvBNwkxczpNN1zCs7TgtU18aexnIKEsCTrifgYS sMT9VCW+MAFLgoG4n4EELHE/VYkvTMCSYCDuZyABS9xPVeILE7AkGIj7Gfj/AwteimSiKE1YAAAA AElFTkSuQmCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADwDoAy8KAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAA AAAAAAEPAPIDRgIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAEEAcgBpAGEA bAAAAG4AZwBzAAAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMTAHg6CzDwgxMAAAAAAA8A1QcA AAQAEAC3D0QAAACLW1NPAABhAGwAAABuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMALFnyB/CD EwB4Ogsw8IMTAAAAAAAPANUHhgAEACAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBh AG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVBwAABhIwALcPRAAAAFYAZQByAGQA YQBuAGEAAAB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMTAHg6CzDwgxMAAAAAAA8A1QcA AAQiQAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMALFnyB/CD EwB4Ogsw8IMTAAAAAAAPANUHAgAGAgAApA8KAAAAgABBAAAAAwAAAAAApQ8MAAAAAAAACC4AAAAH AAAAAACpDwoAAAAHAAAAAAAECAkEQACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAAAAAAAAA AABAAgAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSSAgAADwAA8IoCAAAAAAbweAEAABy0AAAuAAAA gwAAAAgAAAAAAAAABwAAAAIAAAAJAAAAAwAAABsAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAYAAAAA AAAABgAAAAAAAAAIAAAAAAAAAAoAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAAFAAAAAAA AAAVAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAQAAAAAAAA ABAAAAAAAAAACwAAAAAAAAAMAAAAAAAAADIAAAAAAAAAMQAAAAAAAAANAAAAAAAAABAAAAAAAAAA CwAAAAAAAAANAAAAAAAAAA4AAAAAAAAADQAAAAAAAAAKAAAAAAAAAAoAAAAiAAAACwAAACMAAAAL AAAAAAAAAAQAAAAAAAAABAAAACYAAAAbAAAAAAAAABgAAAAAAAAABAAAACkAAAAeAAAAAAAAAAQA AAArAAAAGQAAAAAAAAAEAAAALQAAABwAAAAfAAHwLAAAAGIAB/AkAAAABgbC4XgVSvjpjXtoAv9f jTPz/wDm1AAAIAAAAAAAAAAAAAAAowEL8JwAAACBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAAA AACHAAAAAACIAAAAAAC/AAAAAgCAAQAAAACBAQUAAAiCAQAAAQCDAQAAAAiEAQAAAQCGQQAAAAC/ ARAAEADAAQEAAAjBAQAAAQDCAf///wDEAQAAAADFQQAAAADLATUlAADNAQAAAADOAQAAAADXAQIA AAD/AQgACAABAgIAAAgTACLxBgAAAL8BAAAgABAAGvEEAAAA/zMAAEAAHvEQAAAABAAACAEAAAgC AAAI9wAAEB8A8A84AAAAAADzAxQAAAAFAAAABAAAAAAAAAAWAACAAAAAAAAA8wMUAAAABgAAAAQA AAAAAAAAFwAAgAAAAAAPANAHMwEAAB8AFAQcAAAAAAAVBBQAAAC6k7D2AMqaO60HlMcAypo7AQEA AA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEwAAABkAAAATAAAAGQAAAAAAAAAaBv/BgiEEwB4 OgswAAAAAAAAAACg////7P7//wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A EwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAANIQTABL0CjBolhMACFnyBwAAAAAAAAAAAAAA AAAAAAAAARMAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAA8AiBM4AAAADwCKEzAAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQIAAAAcLUAAHC1AAAPAPAPjAMAAAAA8wMU AAAAAwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPLQAAAFJlc3BvbnNpbGJlIFBl ZXIoUlApIFJlcGxpY2F0aW9uC2luIERIVCBsZXZlbAAAoQ8UAAAALgAAAAAAAAAAAC4AAAAAAAIA JAAQAJ8PBAAAAAUAAAAAAKgPJQAAAFNvbmcgWW9uZ2NoYW8NKG1lbG9keXNvbmdAaHVhd2VpLmNv bSkAAPMDFAAAAAQAAAAEAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDyMAAABTdGVwMTog Q2hvb3NlIGxvY2F0aW9uIHRvIHJlcGxpY2F0ZRAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8UAAAA AgAAAAAAAQAAAA4AAgAAAAAAAAAAAPMDFAAAAAcAAAAEAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAA AAAAAACoDx8AAABTdGVwMjogd2hlbiByZXBsaWNhIG5vZGVzIGZhaWwgEACfDwQAAAABAAAAAACo DwEAAAAgAAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACQAAAAQAAAACAAAABgEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPIgAAAFN0ZXAzOiB3aGVuIHJlc3BvbnNpYmxlIHBlZXIgZmFp bHMQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADzAxQA AAALAAAABAAAAAIAAAAKAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAAU3RlcDQ6IHdoZW4gdGhl IFJQIGNoYW5nZXMgZ3JhY2VmdWxseQAAoQ8UAAAAJgAAAAAAAAAAACYAAAAAAAIAIAAQAJ8PBAAA AAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADzAxQAAAAKAAAABAAA AAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA80AAAAU3RlcDU6IGhhbmRsZSByZXF1ZXN0cyB3 aGVuIHJlc3BvbnNpYmxlIHBlZXIgaXMgYnVzeQAAoQ8UAAAANQAAAAAAAAAAADUAAAAAAAIAIAAQ AJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADqAwAAAAAP APgDBBAAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAswYADwByAAAAD///8AAAAAAF9f XwAAZmYAM8zMAJnMzAAAZmYAsrKyAGAA8AcgAAAA////AAAAAABfX18AMzNmAMyZ/wCZzMwAZmaZ AGYAZgBgAPAHIAAAAP///wAAAAAAQ0NDAAAAzACZzAAA/8wAAP8AAACAgIAAYADwByAAAABkqq4A AAAAAF9fXwD//8wAtLHbAGHB1wAlcXcAzMzMAGAA8AcgAAAAKihaAPj4+ABfX18A////AJmZZgCM i50ARlF0AMDAwABgAPAHIAAAADYEBAD///8AQ0NDAP///wBmmQAAzGYAAMwzAACAgIAAYADwByAA AAAAAAAA////AENDQwCChf4AZpkAAJkA/wBmAMwAgICAAGAA8AcgAAAAAAAAAP///wBDQ0MAAGb/ ADOZZgD/zAAAzAAAAICAgABgAPAHIAAAAGaZAAD///8AMzMAAP//zADMzAAAmcwAADNmAAD//2YA YADwByAAAABmAAAA///MADMzMwDMzMwA/2YAAMwzAACZAAAAzJkAAAAAow8+AAAAAQD//T8AAAAi IAIAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAAAQAAAP//JAAAAAADAAAQAKMP kgAAAAUA//0/AA8AoQAEAEYAAAAAAwAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAAADAAEAAAD/ /x0AAAAAAQAAoAUAAGwAAAAABdQBIAEAAAIAGQDgBQAAoQBBAAAAAAPQAkACAAACABYA4AUAAGwA RgAAAAAF8ANgAwAAAgATAOAFAAChADwAAAAAAxAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABk AAAAAP8AAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASAB AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9QAAAABQAAAAEBAAAO AAAAAAAAAAEAAQkAAA4AAQAgAQAAAAACAAEJAAAOAAEAQAIAAAAAAwABCQAADgABAGADAAAAAAQA AQkAAA4AAQCABAAAAABgAKMPDgAAAAEAAAAAAAAAAAACACgAcACjDz4AAAAFAAAAAAAAAAAAAgAZ AAEAAAAAAAAAAgAVAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgARAAQAAAAAAAAAAgARAIAAow8+AAAA BQAAAAAAAAAAAAIAFQABAAAAAAAAAAIAEwACAAAAAAAAAAIAEgADAAAAAAAAAAIADwAEAAAAAAAA AAIADwAPAAwEfgsAAA8AAvB2CwAAIAII8AgAAAAKAAAACogAAA8AA/AOCwAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACIAAAFAAAADwAD8DYGAAAPAATwVAAAAAEACfAQ AAAACPj//wAAAABgFQAAYAkAAAIACvAIAAAAAogAAAECAAATAAvwBgAAAIgDAAAAABMAIvEGAAAA vwMAAAAEAAAQ8AgAAAAAAAj4YBVgCQ8ABPDAAgAAQgYK8AgAAAADiAAAAgoAAEMBC/BIAgAAfwAA AAQAgAD80ukJQAEAg///QQEAg///QgEAfQAAQwEAfQAARcF2AAAARsEQAAAARwF4RwAASAFgh/// SQEYewAAUcEAAAAAVcFOAAAAVsHmAAAAV8EWAAAAWAEBAAAAfwECAAIAgQEFAAAIvwEQABAA/wEA AAgADgAQAAgAAIP//wCD//8AfQAAAH0AAAoAAIALAACADQAAgA4AAIAAg///AIP//wB9AAAAfQAA EgAAgA4AAIATAACAFAAAgAAAAIAUAACAAAAAgBgAAIAAg///AIP//wB9AAAAfQAAFwAAgBgAAIAW AACACwAAgAUACAACAAimAgAEpQFgAIACAAQAJAAgAAAAAAEAAAEBAAAAAAAAAAAAAACD//8AfQAA AIP//wB9AAAgAAAAAAEAAAIBAAAAAAAAAAAAAACD//8AfQAAAIP//wB9AAAcACAACAAAIEcBAAAA AAAgSAEAAAAAACBJAQAAAAAPIAAEAH0AfQ8gAQQAfQB9DyACBAB9AH0AgAAAAAADBACAAAAAAAQE AIAAAAAABQQAwAAABAQABAbgCQQEBAAEBuAJBAEEBgQAwAAABQQABAbgDAQFBAAEBuAMBAIEAwQA IAsEAAABAAAgDgQBAAAAAMAAAA4EAwQG4BEECAQNBAbgEQQABA0EBuARBAMEEAQAwAAABgQLBAbg FQQHBAoEBuAVBAAECgQG4BUEBgQPBARgCgQNBAAABWAIBAcEAAAFYBoEAAQAAAEABAAQABsAAIAL AACAGQAAgA4AAIATACLxBgAAAL8DAAAABAAAD/AQAAAACPj//7ABAAAoAgAAYAkAAA8ADfAyAAAA AACfDwQAAAAEAAAAAAChDx4AAAABAAAAAAAwAAAAAgAAAAAAAQAAAAAAQwACAAIAGAAPAATwmgIA AEIGCvAIAAAABIgAAAIKAABDAQvwSAIAAH8AAAAEAIAABN3pCUABAIP//0EBAIP//0IBAH0AAEMB AH0AAEXBdgAAAEbBEAAAAEcBnUYAAEgBYIf//0kBAH0AAFHBAAAAAFXBTgAAAFbB5gAAAFfBFgAA AFgBAQAAAH8BAgACAIEBBgAACL8BEAAQAP8BAAAIAA4AEAAIAACD//8Ag///AH0AAAB9AAAKAACA CwAAgA0AAIAOAACAAIP//wCD//8AfQAAAH0AABIAAIAOAACAEwAAgBQAAIAAAACAFAAAgAAAAIAY AACAAIP//wCD//8AfQAAAH0AABcAAIAYAACAFgAAgAsAAIAFAAgAAgAIpgIABKUBYACAAgAEACQA IAAAAAABAAABAQAAAAAAAAAAAAAAg///AH0AAACD//8AfQAAIAAAAAABAAACAQAAAAAAAAAAAAAA g///AH0AAACD//8AfQAAHAAgAAgAACBHAQAAAAAAIEgBAAAAAAAgSQEAAAAADyAABAB9AH0PIAEE AH0AfQ8gAgQAfQB9AIAAAAAAAwQAgAAAAAAEBACAAAAAAAUEAMAAAAQEAAQG4AkEBAQABAbgCQQB BAYEAMAAAAUEAAQG4AwEBQQABAbgDAQCBAMEACALBAAAAQAAIA4EAQAAAADAAAAOBAMEBuARBAgE DQQG4BEEAAQNBAbgEQQDBBAEAMAAAAYECwQG4BUEBwQKBAbgFQQABAoEBuAVBAYEDwQEYAoEDQQA AAVgCAQHBAAABWAaBAAEAAABAAQAEAAbAACACwAAgBkAAIAOAACAEwAi8QYAAAC/AwAAAAQAAA/w EAAAAAj6//8AAAAApQEAAMMHAAAPAA3wDAAAAAAAnw8EAAAABAAAAA8ABPBoAAAAQgEK8AgAAAAF iAAAAgoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGcMQAA/wEYABgAAQICAAAI EwAi8QYAAAC/AwAAAAQAAA/wEAAAAGADAADAAwAAYBUAAMADAAAPAATw1AAAABIACvAIAAAABogA AAAKAACjAAvwPAAAAH8AAQAFAIAAtObpCYcAAgAAAL8AAAACAIEBBAAACIMBAAAACL8BAQARAMAB AQAACP8BAQAJAAECAgAACBMAIvEGAAAAvwMAAAAEAAAQ8AgAAAC+AF8DXhWOAw8AEfAQAAAAAADD CwgAAAAAAAAAAQDpCQ8ADfBCAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1h c3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAADwAE8BgBAAASAArwCAAAAAeIAAAACgAAkwAL 8DYAAAB/AAEABQCAAETp6Qm/AAAAAgCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgTACLxBgAAAL8DAAAABAAAEPAIAAAAfwRfA14Vnw4PABHwEAAAAAAAwwsIAAAAAQAAAAIA6QkP AA3wjAAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHls ZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8e AAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQADwAE8NgAAAASAArwCAAAAAiIAAAACgAA kwAL8DYAAAB/AAEABQCAAKzu6QmHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgjACLxDAAAAL8BAABgAL8DAAAABAAAEPAIAAAAYA8gAWAGgBAPABHwEAAAAAAAwwsIAAAA AgAAAAcB6QkPAA3wRgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAADAAAAAC AAAAAAACAAAAAAADAAMADAAAAPgPBAAAAAAAAAAPAATw2gAAABIACvAIAAAACYgAAAAKAACTAAvw NgAAAH8AAQAFAIAA0PjpCYcAAgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAA CCMAIvEMAAAAvwEAAGAAvwMAAAAEAAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAA CQLpCQ8ADfBIAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8eAAAAAgAAAAAAMAgAAAIAAAAA AAEAAgAAAAAAAwADAAwAAAD6DwQAAAAAAAAADwAE8NoAAAASAArwCAAAAAqIAAAACgAAkwAL8DYA AAB/AAEABQCAALAF6gmHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgj ACLxDAAAAL8BAABgAL8DAAAABAAAEPAIAAAAYA8gEGAVgBAPABHwEAAAAAAAwwsIAAAABAAAAAgC 6gkPAA3wSAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPHgAAAAIAAAAAADAIAAACAAAAAAAC AAIAAAAAAAMAAwAMAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABiAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAF9fXwAAZmYAM8zMAJnMzAAAZmYAsrKyAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAEhPAAQCT198gALoPDgAAAEUAYwBsAGkAcABz AGUADwDuA80LAAACAO8DGAAAAAIAAAADBAcJCAAAABYAAIAAAAAAAAALMA8ADAQ9CwAADwAC8DUL AAAwAgjwCAAAAAoAAAAKjAAADwAD8M0KAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAIwAAAUAAAAPAAPwPAYAAA8ABPBUAAAAAQAJ8BAAAAAS+P//wAAAAGAVAABgDAAA AgAK8AgAAAACjAAAAQIAABMAC/AGAAAAiAMAAAAAEwAi8QYAAAC/AwAAAAQAABDwCAAAAMAAEvhg FWAMDwAE8GgAAABCAQrwCAAAAAOMAAACCgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEA AAjLAZwxAAD/ARgAGAABAgIAAAgTACLxBgAAAL8DAAAABAAAD/AQAAAAkAMAADAGAABgFQAAMAYA AA8ABPDAAgAAQgYK8AgAAAAEjAAAAgoAAEMBC/BIAgAAfwAAAAQAgADYEuoJQAEAg///QQEAg/// QgEAfQAAQwEAfQAARcF2AAAARsEQAAAARwEzLwAASAEAg///SQEAfQAAUcEAAAAAVcFOAAAAVsHm AAAAV8EWAAAAWAEBAAAAfwECAAIAgQEFAAAIvwEQABAA/wEAAAgADgAQAAgAAIP//wCD//8AfQAA AH0AAAoAAIALAACADQAAgA4AAIAAg///AIP//wB9AAAAfQAAEgAAgA4AAIATAACAFAAAgAAAAIAU AACAAAAAgBgAAIAAg///AIP//wB9AAAAfQAAFwAAgBgAAIAWAACACwAAgAUACAACAAimAgAEpQFg AIACAAQAJAAgAAAAAAEAAAEBAAAAAAAAAAAAAACD//8AfQAAAIP//wB9AAAgAAAAAAEAAAIBAAAA AAAAAAAAAACD//8AfQAAAIP//wB9AAAcACAACAAAIEcBAAAAAAAgSAEAAAAAACBJAQAAAAAPIAAE AH0AfQ8gAQQAfQB9DyACBAB9AH0AgAAAAAADBACAAAAAAAQEAIAAAAAABQQAwAAABAQABAbgCQQE BAAEBuAJBAEEBgQAwAAABQQABAbgDAQFBAAEBuAMBAIEAwQAIAsEAAABAAAgDgQBAAAAAMAAAA4E AwQG4BEECAQNBAbgEQQABA0EBuARBAMEEAQAwAAABgQLBAbgFQQHBAoEBuAVBAAECgQG4BUEBgQP BARgCgQNBAAABWAIBAcEAAAFYBoEAAQAAAEABAAQABsAAIALAACAGQAAgA4AAIATACLxBgAAAL8D AAAABAAAD/AQAAAA0Pn//2ADAADQAgAAYAwAAA8ADfAyAAAAAACfDwQAAAAEAAAAAAChDx4AAAAB AAAAAAAwAAAAAgAAAAAAAQAAAAAAQwACAAIAGAAPAATwoAIAAEIGCvAIAAAABYwAAAIKAABTAQvw TgIAAH8AAAAEAIAA4BzqCb8AAAACAEABAIP//0EBAIP//0IBAH0AAEMBAH0AAEXBdgAAAEbBEAAA AEcBMkoAAEgBw4r//0kBAH0AAFHBAAAAAFXBTgAAAFbB5gAAAFfBFgAAAFgBAQAAAH8BAgACAIEB BgAACL8BEAAQAP8BAAAIAA4AEAAIAACD//8Ag///AH0AAAB9AAAKAACACwAAgA0AAIAOAACAAIP/ /wCD//8AfQAAAH0AABIAAIAOAACAEwAAgBQAAIAAAACAFAAAgAAAAIAYAACAAIP//wCD//8AfQAA AH0AABcAAIAYAACAFgAAgAsAAIAFAAgAAgAIpgIABKUBYACAAgAEACQAIAAAAAABAAABAQAAAAAA AAAAAAAAg///AH0AAACD//8AfQAAIAAAAAABAAACAQAAAAAAAAAAAAAAg///AH0AAACD//8AfQAA HAAgAAgAACBHAQAAAAAAIEgBAAAAAAAgSQEAAAAADyAABAB9AH0PIAEEAH0AfQ8gAgQAfQB9AIAA AAAAAwQAgAAAAAAEBACAAAAAAAUEAMAAAAQEAAQG4AkEBAQABAbgCQQBBAYEAMAAAAUEAAQG4AwE BQQABAbgDAQCBAMEACALBAAAAQAAIA4EAQAAAADAAAAOBAMEBuARBAgEDQQG4BEEAAQNBAbgEQQD BBAEAMAAAAYECwQG4BUEBwQKBAbgFQQABAoEBuAVBAYEDwQEYAoEDQQAAAVgCAQHBAAABWAaBAAE AAABAAQAEAAbAACACwAAgBkAAIAOAACAEwAi8QYAAAC/AwAAAAQAAA/wEAAAABL4///AAAAAAgIA ALAKAAAPAA3wDAAAAAAAnw8EAAAABAAAAA8ABPDUAAAAEgAK8AgAAAAGjAAAAAoAAKMAC/A8AAAA fwABAAUAgACQJuoJhwACAAAAvwAAAAIAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIEwAi8QYAAAC/AwAAAAQAABDwCAAAAG0CjQNdFfsFDwAR8BAAAAAAAMMLCAAAAAAAAAADAOoJ DwAN8EIAAAAAAJ8PBAAAAAYAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0 eWxlAACiDwYAAAAhAAAAAAAPAATw0QAAABIACvAIAAAAB4wAAAAKAACTAAvwNgAAAH8AAQAFAIAA sCnqCb8AAAACAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACBMAIvEGAAAAvwMA AAAEAAAQ8AgAAABvCI0DXRW/DA8AEfAQAAAAAADDCwgAAAABAAAABADqCQ8ADfBFAAAAAACfDwQA AAAFAAAAAACoDyMAAABDbGljayB0byBlZGl0IE1hc3RlciBzdWJ0aXRsZSBzdHlsZQAAog8GAAAA JAAAAAAADwAE8NgAAAASAArwCAAAAAiMAAAACgAAkwAL8DYAAAB/AAEABQCAAMAs6gmHAAIAAACB AQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgjACLxDAAAAL8BAABgAL8DAAAABAAA EPAIAAAAYA8gAWAGgBAPABHwEAAAAAAAwwsIAAAAAgAAAAcB6gkPAA3wRgAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPHAAAAAIAAAAAADAAAAACAAAAAAACAAAAAAADAAMADAAAAPgPBAAAAAAA AAAPAATw2gAAABIACvAIAAAACYwAAAAKAACTAAvwNgAAAH8AAQAFAIAAEDjqCYcAAgAAAIEBBAAA CIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACCMAIvEMAAAAvwEAAGAAvwMAAAAEAAAQ8AgA AABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQLqCQ8ADfBIAAAAAACfDwQAAAAEAAAAAACg DwIAAAAqAAAAoQ8eAAAAAgAAAAAAMAgAAAIAAAAAAAEAAgAAAAAAAwADAAwAAAD6DwQAAAAAAAAA DwAE8NoAAAASAArwCAAAAAqMAAAACgAAkwAL8DYAAAB/AAEABQCAAKBB6gmHAAIAAACBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgjACLxDAAAAL8BAABgAL8DAAAABAAAEPAIAAAA YA8gEGAVgBAPABHwEAAAAAAAwwsIAAAABAAAAAgC6gkPAA3wSAAAAAAAnw8EAAAABAAAAAAAoA8C AAAAKgAAAKEPHgAAAAIAAAAAADAIAAACAAAAAAACAAIAAAAAAAMAAwAMAAAA2A8EAAAAAAAAAA8A BPBIAAAAEgAK8AgAAAABjAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAF9fXwAAZmYAM8zMAJnMzAAAZmYA srKyAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4I AAAAEhPAAQCT198PAO4DMAIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAFwAAgAAAAAAHAAswDwAMBKAB AAAPAALwmAEAACAACPAIAAAAAwAAAAgIAAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA AAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPB4AAAAEgAK8AgAAAACCAAAIAIAAGMAC/AkAAAA BAAAAAAAfwAAAAQAgAA4yvIHvwEAAAEA/wEAAAEAAQMGjAAAAAAQ8AgAAABtAo0DXRX7BQ8AEfAQ AAAAAADDCwgAAAAAAAAADwDyBw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMI AAAgAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAFC78ge/AQAAAQD/AQAAAQABAweMAAAAABDwCAAA AG8IjQNdFb8MDwAR8BAAAAAAAMMLCAAAAAEAAAAQAPIHDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw SAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAA ACY2yAGgY4kkDwDuA1kLAAACAO8DGAAAAAEAAAANDgAAAAAAABYAAIAAAAAABwALMA8ADARwCgAA DwAC8GgKAAAwAAjwCAAAABIAAAAaDAAADwAD8OgJAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAA AAAAAAAAAAIACvAIAAAAAAwAAAUAAAAPAATwZgAAADIACvAIAAAADgwAAAAKAACDAAvwMAAAAIUA AgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACBMAIvEGAAAAvwEA AGAAAAAQ8AgAAAD1BSoEzhF2Dg8ABPB4AAAAEgAK8AgAAAACDAAAIAIAAGMAC/AkAAAABAAAAAAA fwAAAAQAgACQR/8GvwEAAAEA/wEAAAEAAQMGiAAAAAAQ8AgAAAC+AF8DXhWOAw8AEfAQAAAAAADD CwgAAAAAAAAADQD/Bg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMMAAAgAgAA YwAL8CQAAAAEAAAAAAB/AAAABACAAHDI/wa/AQAAAQD/AQAAAQABAweIAAAAABDwCAAAAH8EXwNe FZ8ODwAR8BAAAAAAAMMLCAAAAAEAAAAOAP8GDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwVAAAALIE CvAIAAAACAwAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAa WZJaU08pAAAAAAAQ8AgAAABmDQYNUw95Dw8ABPBUAAAAsgQK8AgAAAAJDAAAAAoAAEMAC/AsAAAA fwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAACUJvhAL EzgLDwAE8FQAAACyBArwCAAAAAoMAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEA AACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAAbQUGDVMPgAcPAATwVAAAALIECvAIAAAACwwA AAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAA AAAQ8AgAAAASBUoGlwglBw8ABPBUAAAAsgQK8AgAAAAMDAAAAAoAAEMAC/AsAAAAfwCAAIAABEEB AAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAAMsIGQNmBd4KDwAE8FQA AACyBArwCAAAAA0MAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXUR gSgAGlmSWlNPKQAAAAAAEPAIAAAACw2VBeIHHg8PAATwAAEAAPIDCvAIAAAADwwAAAAKAAATAQvw ZgAAAH8AAACAAIAAJFDlCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAL8AAAACAEcBsPT//0gBcD8A AIEBBQAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACD8DAAAQAH8DAAAMABMAIvEGAAAA vwEAAGAAAAAQ8AgAAAACBPIPgBY0Bw8ADfBcAAAAAACfDwQAAAAEAAAAAACoDyoAAABDaG9vc2Ug cGVlciBBLCBCIHRvIHJlcGxpY2F0ZSBhIGtleU0vdmFsdWUAAKEPFgAAACsAAAAAAAAIAAABACsA AAAAAAEAAwAPAATwdgAAAEIBCvAIAAAAEAwAAEAKAADTAAvwTgAAAIEAkF8BAIIA0LYAAIMAkF8B AIQA0LYAAL8AAAACAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNABAQAAANEBAQAAAP8BGAAYAAEC AgAACAAAEPAIAAAAMgdnBQYNCAoPAATwdgAAAEIBCvAIAAAAEQwAAAAKAADTAAvwTgAAAIEAkF8B AIIA0LYAAIMAkF8BAIQA0LYAAL8AAAACAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNABAQAAANEB AQAAAP8BGAAYAAECAgAACAAAEPAIAAAAYAfoDRkRrgkPAATwwwAAAKIMCvAIAAAAFAwAAAAKAADj AAvwVAAAAIAAjHzgCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEB BQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAAA/ ClsTLxQmCw8ADfAxAAAAAACfDwQAAAAEAAAAAACoDwEAAABBAAChDxQAAAACAAAAAAAAAAAAAgAA AAAAAQADAA8ABPDDAAAAogwK8AgAAAAVDAAAAAoAAOMAC/BUAAAAgACUo+AJgQCQXwEAggDQtgAA gwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAIoJ/gHTAnEKDwAN8DEAAAAAAJ8PBAAAAAQA AAAAAKgPAQAAAEIAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAABAAMADwAE8NYAAACiDArwCAAAABYM AAAACgAA4wAL8FQAAACAAJSC4wmBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/ AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAA EPAIAAAAigSbCz4QHgYPAA3wRAAAAAAAnw8EAAAABAAAAAAAqA8UAAAAUlAocmVzcG9uc2libGUN cGVlcikAAKEPFAAAABUAAAAAAAAAAAAVAAAAAAABAAMADwAE8M0AAACiDArwCAAAABcMAAAACgAA 4wAL8FQAAACAAMA06QmBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCB AQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAA eQj0BgcLYAkPAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8LAAAAbWFpbnRlbmFuY2UAAKEPFAAAAAwA AAAAAAAAAAAMAAAAAAABAAMADwAE8M0AAACiDArwCAAAABgMAAAACgAA4wAL8FQAAACAANCS4AmB AJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAQwgzDUYRKgkPAA3wOwAA AAAAnw8EAAAABAAAAAAAqA8LAAAAbWFpbnRlbmFuY2UAAKEPFAAAAAwAAAAAAAAAAAAMAAAAAAAB AAMADwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAfAAXwEAAAAAAAF/AIAAAAAgAAAA8MAAAQAPAHIAAA AP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAAmNsgBQNEfOgAAACsEAAAAAAAAAB8ARPE9 AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAygj/////EgAAAA8APfENAAAAQAFC8QUA AAABCQAAAA8AAisAAAAADwDuA+YQAAACAO8DGAAAAAEAAAANDgAAAAAAABYAAIAAAAAABwALMA8A DAT9DwAADwAC8PUPAABgAgjwCAAAABkAAAAamAAADwAD8HUPAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAJgAAAUAAAAPAATwZgAAADIACvAIAAAAApgAAAAKAACDAAvw MAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACBMAIvEG AAAAvwEAAGAAAAAQ8AgAAAD1BSoEzhF2Dg8ABPB+AAAAEgAK8AgAAAADmAAAIAIAAHMAC/AqAAAA BAAAAAAAfwAAAAQAgABAZeMJvwEAAAEA/wEAAAEAAQMGiAAAiAMAAAAAAAAQ8AgAAAC+AF8DXhWO Aw8AEfAQAAAAAADDCwgAAAAAAAAADQDjCQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8H4AAAASAArw CAAAAASYAAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACAAGRq4wm/AQAAAQD/AQAAAQABAweIAACI AwAAAAAAABDwCAAAAH8EXwNeFZ8ODwAR8BAAAAAAAMMLCAAAAAEAAAAOAOMJDwAN8AwAAAAAAJ4P BAAAAAEAAAAPAATwVAAAALIECvAIAAAABZgAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAA AAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABmDQYNUw95Dw8ABPBUAAAAsgQK8AgA AAAGmAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpT TykAAAAAABDwCAAAACUJvhALEzgLDwAE8FQAAACyBArwCAAAAAeYAAAACgAAQwAL8CwAAAB/AIAA gAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAAbQUGDVMPgAcP AATwVAAAALIECvAIAAAACJgAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWN hIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAASBUoGlwglBw8ABPBUAAAAsgQK8AgAAAAJmAAAAAoA AEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDw CAAAAMsIGQNmBd4KDwAE8FQAAACyBArwCAAAAAqYAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAF wRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAACw2VBeIHHg8PAATwFgEAAPID CvAIAAAAC5gAAAAKAAATAQvwZgAAAH8AAACAAIAA3DjjCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYA AL8AAAACAEcBsPT//0gBwDEAAIEBBQAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACD8D AAAQAH8DAAAMABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAACBPIPgBYVCA8ADfByAAAAAACfDwQAAAAE AAAAAACoDz4AAABXaGVuIG9uZSByZXBsaWNhIG5vZGUgZmFpbHMsIFJQIGNob29zZSBhIG5ldyBu b2RlIHRvIHJlcGxpY2F0ZQAAoQ8YAAAAPwAAAAAAAAgAAAEAPwAAAAAAAwADABAADwAE8HYAAABC AQrwCAAAAAyYAABACgAA0wAL8E4AAACBAJBfAQCCANC2AACDAJBfAQCEANC2AAC/AAAAAgBEAQQA AAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAADIHZwUG DQgKDwAE8HYAAABCAQrwCAAAAA2YAAAACgAA0wAL8E4AAACBAJBfAQCCANC2AACDAJBfAQCEANC2 AAC/AAAAAgBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgA ABDwCAAAAGAH6A0ZEa4JDwAE8MMAAACiDArwCAAAAA6YAAAACgAA4wAL8FQAAACAAOxD4wmBAJBf AQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAPwpbEy8UJgsPAA3wMQAAAAAA nw8EAAAABAAAAAAAqA8BAAAAQQAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAEAAwAPAATwwwAAAKIM CvAIAAAAD5gAAAAKAADjAAvwVAAAAIAA9E3jCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAA AIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAA vwEAACAAAAAQ8AgAAACKCf4B0wJxCg8ADfAxAAAAAACfDwQAAAAEAAAAAACoDwEAAABCAAChDxQA AAACAAAAAAAAAAAAAgAAAAAAAQADAA8ABPDEAAAAogwK8AgAAAAQmAAAAAoAAOMAC/BUAAAAgABc fuAJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAIoEuw3oDnEFDwAN 8DIAAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAFJQAAChDxQAAAADAAAAAAAAAAAAAwAAAAAAAQADAA8A BPDNAAAAogwK8AgAAAARmAAAAAoAAOMAC/BUAAAAgAAYLNEIgQCQXwEAggDQtgAAgwCQXwEAhADQ tgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI EwAi8QYAAAC/AQAAIAAAABDwCAAAAHkI9AYHC2AJDwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAA AG1haW50ZW5hbmNlAAChDxQAAAAMAAAAAAAAAAAADAAAAAAAAQADAA8ABPDNAAAAogwK8AgAAAAS mAAAAAoAAOMAC/BUAAAAgABcGNEIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAA vwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAA ABDwCAAAAEMIMw1GESoJDwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAG1haW50ZW5hbmNlAACh DxQAAAAMAAAAAAAAAAAADAAAAAAAAQADAA8ABPDKAAAAogwK8AgAAAATmAAAAAoAAOMAC/BUAAAA gAD8i+AJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAOgHTQmHCggJ DwAN8DgAAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAFggAAChDxoAAAADAAAAAAAAAAAAAwAAAAAABwAD ABgA/zMA/g8ABPDQAAAAogwK8AgAAAAUmAAAAAoAAOMAC/BUAAAAgABQZ8sIgQCQXwEAggDQtgAA gwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAI0HhwfLC3QIDwAN8D4AAAAAAJ8PBAAAAAQA AAAAAKgPDgAAAERldGVjdCBmYWlsdXJlAAChDxQAAAAPAAAAAAAAAAAADwAAAAAAAQADAA8ABPB2 AAAAQgEK8AgAAAAVmAAAQAoAANMAC/BOAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIA RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABg B4cHjg1mDQ8ABPDUAAAAogwK8AgAAAAWmAAAAAoAAOMAC/BUAAAAgAAYbcsIgQCQXwEAggDQtgAA gwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAK0O8QPZCZQPDwAN8EIAAAAAAJ8PBAAAAAQA AAAAAKgPEgAAAE5ldyByZXBsaWNhIG5vZGUgQwAAoQ8UAAAAEwAAAAAAAAAAABMAAAAAAAEAAwAP AATwzQAAAKIMCvAIAAAAGJgAAAAKAADjAAvwVAAAAIAAOIbjCYEAkF8BAIIA0LYAAIMAkF8BAIQA 0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAA CBMAIvEGAAAAvwEAACAAAAAQ8AgAAABjCsUI2AxKCw8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsA AABtYWludGVuYW5jZQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAEAAwAPAATwygAAAKIMCvAIAAAA GZgAAAAKAADjAAvwVAAAAIAAwFvjCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAA AL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAA AAAQ8AgAAADoB00JhwoICQ8ADfA4AAAAAACfDwQAAAAEAAAAAACoDwIAAABYIAAAoQ8aAAAAAwAA AAAAAAAAAAMAAAAAAAcAAwAYAP8zAP4PAATwygAAAKIMCvAIAAAAGpgAAAAKAADjAAvwVAAAAIAA zBHKCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAABTCaID3ARzCg8A DfA4AAAAAACfDwQAAAAEAAAAAACoDwIAAABYIAAAoQ8aAAAAAwAAAAAAAAAAAAMAAAAAAAcAAwAY AP8zAP4PAATwSAAAABIACvAIAAAAAZgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB 3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABAB8ABfAQAAAAAAAX8AgAAAABAAAAC5gAABAA8Acg AAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAA AABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAACY2yAFA0R86AAAAKwQAAAAAAAAAHwBE 8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADKCP////8SAAAADwA98Q0AAABAAULx BQAAAAEJAAAADwACKwAAAAAPAO4Djg8AAAIA7wMYAAAAAQAAAA0OAAAAAAAAFgAAgAAAAAAHAAsw DwAMBKUOAAAPAALwnQ4AAJACCPAIAAAAGAAAAB2kAAAPAAPwNQ4AAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAApAAABQAAAA8ABPBmAAAAMgAK8AgAAAACpAAAAAoAAIMA C/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi 8QYAAAC/AQAAYAAAABDwCAAAAPUFKgTOEXYODwAE8H4AAAASAArwCAAAAAOkAAAgAgAAcwAL8CoA AAAEAAAAAAB/AAAABACAAJgr4Am/AQAAAQD/AQAAAQABAwaIAACIAwAAAAAAABDwCAAAAL4AXwNe FY4DDwAR8BAAAAAAAMMLCAAAAAAAAAANAOAJDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwfgAAABIA CvAIAAAABKQAACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAyAfgCb8BAAABAP8BAAABAAEDB4gA AIgDAAAAAAAAEPAIAAAAfwRfA14Vnw4PABHwEAAAAAAAwwsIAAAAAQAAAA4A4AkPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBUAAAAsgQK8AgAAAAFpAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEU AAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAAGYNBg1TD3kPDwAE8FQAAACyBArw CAAAAAakAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmS WlNPKQAAAAAAEPAIAAAAkApjELASowwPAATwVAAAALIECvAIAAAAB6QAAAAKAABDAAvwLAAAAH8A gACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABtBQYNUw+A Bw8ABPBUAAAAsgQK8AgAAAAIpAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAA hY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAABIFSgaXCCUHDwAE8FQAAACyBArwCAAAAAmkAAAA CgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAA EPAIAAAAywgZA2YF3goPAATwVAAAALIECvAIAAAACqQAAAAKAABDAAvwLAAAAH8AgACAAARBAQAA AAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAALDZUF4gceDw8ABPB2AAAA QgEK8AgAAAALpAAAQAoAANMAC/BOAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEE AAAAfwEAAAEAvwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAAAyB2cF Bg0ICg8ABPDDAAAAogwK8AgAAAANpAAAAAoAAOMAC/BUAAAAgAAIE+AJgQCQXwEAggDQtgAAgwCQ XwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAD8KWxMvFCYLDwAN8DEAAAAAAJ8PBAAAAAQAAAAA AKgPAQAAAEEAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAABAAMADwAE8MMAAACiDArwCAAAAA6kAAAA CgAA4wAL8FQAAACAAGAA4AmBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIA AgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAI AAAAign+AdMCcQoPAA3wMQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAQgAAoQ8UAAAAAgAAAAAAAAAA AAIAAAAAAAEAAwAPAATwxAAAAKIMCvAIAAAAD6QAAAAKAADjAAvwVAAAAIAA6K3gCYEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAACKBLsN6A5xBQ8ADfAyAAAAAACfDwQA AAAEAAAAAACoDwIAAABSUAAAoQ8UAAAAAwAAAAAAAAAAAAMAAAAAAAEAAwAPAATwzQAAAKIMCvAI AAAAEKQAAAAKAADjAAvwVAAAAIAAGJLgCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcA BgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEA ACAAAAAQ8AgAAAB5CPQGBwtgCQ8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABtYWludGVuYW5j ZQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAEAAwAPAATwygAAAKIMCvAIAAAAEqQAAAAKAADjAAvw VAAAAIAARGHMCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAA CIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAAD1BY4N yA4VBw8ADfA4AAAAAACfDwQAAAAEAAAAAACoDwIAAABYIAAAoQ8aAAAAAwAAAAAAAAAAAAMAAAAA AAcAAwAYAP8zAP4PAATwygAAAKIMCvAIAAAAE6QAAAAKAADjAAvwVAAAAIAATGvMCIEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAADoB3oJtAoICQ8ADfA4AAAAAACfDwQA AAAEAAAAAACoDwIAAABYIAAAoQ8aAAAAAwAAAAAAAAAAAAMAAAAAAAcAAwAYAP8zAP4PAATw0AAA AKIMCvAIAAAAFKQAAAAKAADjAAvwVAAAAIAA/HTMCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUA AgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEG AAAAvwEAACAAAAAQ8AgAAACXByEHZQt+CA8ADfA+AAAAAACfDwQAAAAEAAAAAACoDw4AAABEZXRl Y3QgZmFpbHVyZQAAoQ8UAAAADwAAAAAAAAAAAA8AAAAAAAEAAwAPAATwVAAAALIECvAIAAAAFaQA AAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAA AAAQ8AgAAACqBgkQVhK9CA8ABPBwAAAAQgEK8AgAAAAWpAAAgAoAAMMAC/BIAAAAgQCQXwEAggDQ tgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgA AQICAAAIAAAQ8AgAAADoB+8FCRA2Cg8ABPDSAAAAogwK8AgAAAAXpAAAAAoAAOMAC/BUAAAAgAB0 OcoIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAACwGHRLiFcAHDwAN 8EAAAAAAAJ8PBAAAAAQAAAAAAKgPEAAAAE5ldyBSUCBmb3IgDUtleU0AAKEPFAAAABEAAAAAAAAA AAARAAAAAAABAAMADwAE8HAAAABCAQrwCAAAABikAACACgAAwwAL8EgAAACBAJBfAQCCANC2AACD AJBfAQCEANC2AAC/AAAAAgBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAABAgIA AAgAABDwCAAAAJ0IoRGhEb4KDwAE8NkAAACiDArwCAAAABukAAAACgAA4wAL8FQAAACAACQHywiB AJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAywhtC88SsgkPAA3wRwAA AAAAnw8EAAAABAAAAAAAqA8XAAAAREhUIGxvb2t1cCBhbmQgdHJhbnNmZXIAAKEPFAAAABgAAAAA AAAAAAAYAAAAAAABAAMADwAE8CMBAACiDArwCAAAABykAAAACgAAwwAL8EgAAACAACCMywiBAJBf AQCCANC2AACDAJBfAQCEANC2AAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAAB AgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAATA/5AA8W4BAPAA3wnQAAAAAAnw8EAAAABAAAAAAA qA9tAAAAUmVwbGljYSBwZWVyIGxvb2t1cCB0aGUgbmV3IFJQIHdpdGggbG9va2luZyB1cCBLZXlN IGluIHRoZSBESFQgYW5kIHRyYW5zZmVyIEtleU0vdmFsdWUgdG8gdGhlIG5ldyBSUCBmb3IgS2V5 TQAAoQ8UAAAAbgAAAAAAAAAAAG4AAAAAAAEAAwAPAATwSAAAABIACvAIAAAAAaQAAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg AAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAA AABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAACY2yAFA0R86AAAAKwQAAAAAAAAAHwBE 8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADKCP////8SAAAADwA98Q0AAABAAULx BQAAAAEJAAAADwACKwAAAAAPAO4DFQ4AAAIA7wMYAAAAAQAAAA0OAAAAAAAAFgAAgAAAAAAHAAsw DwAMBCwNAAAPAALwJA0AANACCPAIAAAAFgAAABu0AAAPAAPwvAwAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAtAAABQAAAA8ABPBmAAAAMgAK8AgAAAACtAAAAAoAAIMA C/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi 8QYAAAC/AQAAYAAAABDwCAAAAPUFKgTOEXYODwAE8H4AAAASAArwCAAAAAO0AAAgAgAAcwAL8CoA AAAEAAAAAAB/AAAABACAALxz6gm/AQAAAQD/AQAAAQABAwaIAACIAwAAAAAAABDwCAAAAL4AXwNe FY4DDwAR8BAAAAAAAMMLCAAAAAAAAAANAOoJDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwfgAAABIA CvAIAAAABLQAACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAA3HjqCb8BAAABAP8BAAABAAEDB4gA AIgDAAAAAAAAEPAIAAAAfwRfA14Vnw4PABHwEAAAAAAAwwsIAAAAAQAAAA4A6gkPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBUAAAAsgQK8AgAAAAFtAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEU AAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAAGYNBg1TD3kPDwAE8FQAAACyBArw CAAAAAa0AAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmS WlNPKQAAAAAAEPAIAAAAkApjELASowwPAATwVAAAALIECvAIAAAAB7QAAAAKAABDAAvwLAAAAH8A gACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABtBQYNUw+A Bw8ABPBUAAAAsgQK8AgAAAAItAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAA hY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAABIFSgaXCCUHDwAE8FQAAACyBArwCAAAAAm0AAAA CgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAA EPAIAAAAywgZA2YF3goPAATwVAAAALIECvAIAAAACrQAAAAKAABDAAvwLAAAAH8AgACAAARBAQAA AAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAALDZUF4gceDw8ABPDDAAAA ogwK8AgAAAAMtAAAAAoAAOMAC/BUAAAAgABsxMwIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQAC AAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYA AAC/AQAAIAAAABDwCAAAAD8KWxMvFCYLDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEEAAKEP FAAAAAIAAAAAAAAAAAACAAAAAAABAAMADwAE8MMAAACiDArwCAAAAA20AAAACgAA4wAL8FQAAACA AMzTzAiBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAA AAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAign+AdMCcQoP AA3wMQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAQgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAEAAwAP AATwxAAAAKIMCvAIAAAADrQAAAAKAADjAAvwVAAAAIAADFfMCIEAkF8BAIIA0LYAAIMAkF8BAIQA 0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAA CBMAIvEGAAAAvwEAACAAAAAQ8AgAAACKBLsN6A5xBQ8ADfAyAAAAAACfDwQAAAAEAAAAAACoDwIA AABSUAAAoQ8UAAAAAwAAAAAAAAAAAAMAAAAAAAEAAwAPAATwzQAAAKIMCvAIAAAAD7QAAAAKAADj AAvwVAAAAIAAgLfMCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEB BQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAADL CBAIIwyyCQ8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABtYWludGVuYW5jZQAAoQ8UAAAADAAA AAAAAAAAAAwAAAAAAAEAAwAPAATwVAAAALIECvAIAAAAE7QAAAAKAABDAAvwLAAAAH8AgACAAARB AQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAACqBgkQVhK9CA8ABPB2 AAAAQgEK8AgAAAAUtAAAgAoAANMAC/BOAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIA RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADo B+8FCRA2Cg8ABPDSAAAAogwK8AgAAAAVtAAAAAoAAOMAC/BUAAAAgAAgVMwIgQCQXwEAggDQtgAA gwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAACwGHRLiFcAHDwAN8EAAAAAAAJ8PBAAAAAQA AAAAAKgPEAAAAE5ldyBSUCBmb3IgDUtleU0AAKEPFAAAABEAAAAAAAAAAAARAAAAAAABAAMADwAE 8HYAAABCAQrwCAAAABa0AACACgAA0wAL8E4AAACBAJBfAQCCANC2AACDAJBfAQCEANC2AAC/AAAA AgBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAA AJ0IoRGhEb4KDwAE8CMBAACiDArwCAAAABi0AAAACgAAwwAL8EgAAACAABizzAiBAJBfAQCCANC2 AACDAJBfAQCEANC2AAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgT ACLxBgAAAL8BAAAgAAAAEPAIAAAATA/5AA8W4BAPAA3wnQAAAAAAnw8EAAAABAAAAAAAqA9tAAAA UmVwbGljYSBwZWVyIGxvb2t1cCB0aGUgbmV3IFJQIHdpdGggbG9va2luZyB1cCBLZXlNIGluIHRo ZSBESFQgYW5kIHRyYW5zZmVyIEtleU0vdmFsdWUgdG8gdGhlIG5ldyBSUCBmb3IgS2V5TQAAoQ8U AAAAbgAAAAAAAAAAAG4AAAAAAAEAAwAPAATwcAAAAEIBCvAIAAAAGbQAAAAKAADDAAvwSAAAAIEA kF8BAIIA0LYAAIMAkF8BAIQA0LYAAL8AAAACAEQBBAAAAH8BAAABAL8BAAAQAMAB/8wAANEBAQAA AP8BGAAYAAECAgAACAAAEPAIAAAAUAYmD74QMgcPAATwzQAAAKIMCvAIAAAAGrQAAAAKAADjAAvw VAAAAIAAfO3vB4EAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAA CIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAACACdsP 7hNnCg8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABtYWludGVuYW5jZQAAoQ8UAAAADAAAAAAA AAAAAAwAAAAAAAEAAwAPAATwAQEAAKIMCvAIAAAAG7QAAAAKAADjAAvwVAAAAIAAfN/vB4EAkF8B AIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAABdBFMPoRNjBg8ADfBvAAAAAACf DwQAAAAEAAAAAACoDz0AAABIYW5kb3ZlciB0aGUgDWtleU0vdmFsdWUgYW5kDXJlcGxpY2EgbWFu YWdlbWVudA10byB0aGUgTmV3IFJQAAChDxYAAAA+AAAAAAAAAAAAPgAAAAAAAwADAAwADwAE8EgA AAASAArwCAAAAAG0AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAA DwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAAm NsgBQNEfOgAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA ygj/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuAz8NAAACAO8DGAAAAAEA AAANDgAAAAAAABYAAIAAAAAABwALMA8ADARWDAAADwAC8E4MAACwAgjwCAAAABMAAAAYrAAADwAD 8N4LAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKwAAAUAAAAPAATw ZgAAADIACvAIAAAAAqwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BCAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAQ8AgAAAD1BSoEzhF2Dg8ABPB+AAAA EgAK8AgAAAADrAAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgACcP9EIvwEAAAEA/wEAAAEAAQMG iAAAiAMAAAAAAAAQ8AgAAAC+AF8DXhWOAw8AEfAQAAAAAADDCwgAAAAAAAAADQDRCA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8H4AAAASAArwCAAAAASsAAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACA AMBE0Qi/AQAAAQD/AQAAAQABAweIAACIAwAAAAAAABDwCAAAAH8EXwNeFZ8ODwAR8BAAAAAAAMML CAAAAAEAAAAOANEIDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwVAAAALIECvAIAAAABawAAAAKAABD AAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgA AABmDQYNUw95Dw8ABPBUAAAAsgQK8AgAAAAGrAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEU AAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAACUJvhALEzgLDwAE8FQAAACyBArw CAAAAAesAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmS WlNPKQAAAAAAEPAIAAAAbQUGDVMPgAcPAATwVAAAALIECvAIAAAACKwAAAAKAABDAAvwLAAAAH8A gACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAASBUoGlwgl Bw8ABPBUAAAAsgQK8AgAAAAJrAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAA hY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAAMsIGQNmBd4KDwAE8FQAAACyBArwCAAAAAqsAAAA CgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAA EPAIAAAACw2VBeIHHg8PAATwwwAAAKIMCvAIAAAADqwAAAAKAADjAAvwVAAAAIAAdHjRCIEAkF8B AIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAAA/ClsTLxQmCw8ADfAxAAAAAACf DwQAAAAEAAAAAACoDwEAAABBAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAQADAA8ABPDDAAAAogwK 8AgAAAAPrAAAAAoAAOMAC/BUAAAAgAAkgtEIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAA hwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/ AQAAIAAAABDwCAAAAK4JrwGEApUKDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEIAAKEPFAAA AAIAAAAAAAAAAAACAAAAAAABAAMADwAE8MQAAACiDArwCAAAABCsAAAACgAA4wAL8FQAAACAAJRf 0QiBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/ AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAigS7DegOcQUPAA3w MgAAAAAAnw8EAAAABAAAAAAAqA8CAAAAUlAAAKEPFAAAAAMAAAAAAAAAAAADAAAAAAABAAMADwAE 8DIBAAACAArwCAAAABOsAAAACgAAEwIL8PwAAACBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAAA AACHAAAAAACIAAAAAAC/AAAAAgBCAX4FAABDATMGAABEAQQAAABFwRwAAABGwRQAAAB/AQEAAQCA AQAAAACBAQUAAAiCAQAAAQCDAQAAAAiEAQAAAQCGQQAAAAC/AQAAEADAAQEAAAjBAQAAAQDCAf// /wDEAQAAAADFQQAAAADLATUlAADNAQAAAADOAQAAAADRAQEAAADXAQIAAAD/ARgAGAABAgIAAAgH AAcA8P8AADMGVwBpBK4AoAKYAZgBggKQAN8ERAB+BQAABwAIAAIAAEAArQEgAK0BIACsAIATACLx BgAAAL8BAABgAAAAEPAIAAAA2AZaB9gMCw0PAATw1gAAAKIMCvAIAAAAFKwAAAAKAADjAAvwVAAA AIAAdA3RCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMB AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAACACdIGTQ1n Cg8ADfBEAAAAAACfDwQAAAAEAAAAAACoDxQAAABHZXQgcmVxdWVzdCBmb3IgS2V5TQAAoQ8UAAAA FQAAAAAAAAAAABUAAAAAAAEAAwAPAATwcAAAAEIBCvAIAAAAFawAAAAKAADDAAvwSAAAAIEAkF8B AIIA0LYAAIMAkF8BAIQA0LYAAL8AAAACAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8B GAAYAAECAgAACAAAEPAIAAAAYAdTD0YRrgkPAATw7QAAAKIMCvAIAAAAFqwAAAAKAADjAAvwVAAA AIAADHXRCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMB AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAACNB3AOChUh CQ8ADfBbAAAAAACfDwQAAAAEAAAAAACoDysAAABSZWxheSB0aGUgcmVxdWVzdCB0byANcmVwbGlj YSBub2RlIGZvciBLZXlNAAChDxQAAAAsAAAAAAAAAAAALAAAAAAAAQADAA8ABPDGAAAAogwK8AgA AAAXrAAAAAoAAOMAC/BUAAAAgACIKtEIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAG AAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAA IAAAABDwCAAAAG0FUw8jEVQGDwAN8DQAAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAEJ1c3kAAKEPFAAA AAUAAAAAAAAAAAAFAAAAAAABAAMADwAE8E8BAACiDArwCAAAABisAAAACgAA4wAL8FQAAACAAJjY 4AmBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/ AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAACA84AAoWnBAPAA3w vQAAAAAAnw8EAAAABAAAAAAAqA+NAAAAV2hlbiB0aGUgcmVzcG9uc2libGUgcGVlciBpcyBidXN5 LCBpdCBjYW4gcmVsYXkgcmVxdWVzdHMgZm9yIHRoZSBjZXJ0YWluIGtleQ10byB0aGUgcmVwbGlj YSwgd2hpY2ggY2FuIHByZXZlbnQgaXRzIGJ1c3kgc3RhdHVzIGdldHRpbmcgd29yc2UuAAChDxQA AACOAAAAAAAAAAAAjgAAAAAAAQADAA8ABPBIAAAAEgAK8AgAAAABrAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEADwAF8AAAAAAQAPAH IAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8Q AAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAAAmNsgBQNEfOgAAACsEAAAAAAAAAB8A RPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAygj/////EgAAAA8APfENAAAAQAFC 8QUAAAABCQAAAA8AAisAAAAAAAByFzAAAAABABAAAAAAAAMAUAAYJgAAUCgAADcKAABDGgAAsTMA AAkAMACfRAAAUmIAADVUAAAAAPUPHAAAAAoBAACkGQADAAAAAJlvAAABAAAACwAAAAEAxTEPAOgD LwoAAAEA6R4AAAAQAAAAT24tc2NyZWVuIFNob3cAAB4AAAAgAAAASHVhd2VpIFRlY2hub2xvZ2ll cyBDby4sTHRkLgAAAAADAAAAg/4AAAMAAABAAAAAAwAAAAYAAAADAAAAAAAAAAMAAAAAAAAAAwAA AAAAAAADAAAAqBkLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAwAAAAGAAAA QXJpYWwABQAAAMvOzOUAEAAAAFRpbWVzIE5ldyBSb21hbgAIAAAAVmVyZGFuYQAKAAAAV2luZ2Rp bmdzAAgAAABFY2xpcHNlAC4AAABSZXNwb25zaWJsZSBQZWVyKFJQKSBSZXBsaWNhdGlvbiBpbiBE SFQgbGV2ZWwAJAAAAFN0ZXAxOiBDaG9vc2UgbG9jYXRpb24gdG8gcmVwbGljYXRlACAAAABTdGVw Mjogd2hlbiByZXBsaWNhIG5vZGVzIGZhaWwgACMAAABTdGVwMzogd2hlbiByZXNwb25zaWJsZSBw ZWVyIGZhaWxzACYAAABTdGVwNDogd2hlbiB0aGUgUlAgY2hhbmdlcyBncmFjZWZ1bGx5ADUAAABT dGVwNTogaGFuZGxlIHJlcXVlc3RzIHdoZW4gcmVzcG9uc2libGUgcGVlciBpcyBidXN5AAwQAAAG AAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAAFAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAA AAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABgAAAAAAACUDAgAZACwAmAAsAAQAAAAtAQIA BAAAAC0BAwAEAAAA8AEEAAQAAAAAAPYPHgAAABQAAABfwJHjX/4AAAYA9AMDANowczY0MDgxCAAA AHMANgA0ADAAOAAxAAAALQEBADIAAAAkAxcAAAAaAAQAHAAIAB8ACwAiAA4AJgAQACoAEgAuABMA MwAUADgAEwA8ABIAQQAQAEUADgBJAAsATQAIAFAABABTAAAAVQAAAFUAAABVAAAAGgAAABoAAAAa AAAAGgAEAAAALQECAAQAAAAGAQEABAAAAC0BAwAEAAAAJwH//wQAAADwAQAAAwAAAB4ABwAAAPwC AAAAZmYAAAAEAAAALQEAAAQAAAAGAQEABAAAAC0BAQAyAAAAJAMXAAAADAADAA4ABgARAAgAFQAK ABgADAAcAA0AIAAOACQADgAoAA4ALAANADAADAA0AAoAOAAIADwABgA/AAMAQgAAAEUAAABFAAAA RQAAAAwAAAAMAAAADAAAAAwABAAAAC0BAgAEAAAABgEBAAQAAAAtAQMABAAAACcB//8cAAAA+wL4 /wAAAAAAAAAAAAEPAPIDRgIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAEEA cgBpAGEAbAAAAG4AZwBzAAAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMTAHg6CzDwgxMAAAAA AA8A1QcAAAQAEAC3D0QAAACLW1NPAABhAGwAAABuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMA LFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHhgAEACAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVBwAABhIwALcPRAAAAFYA ZQByAGQAYQBuAGEAAAB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMTAHg6CzDwgxMAAAAA AA8A1QcAAAQiQAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMA LFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAgAGAgAApA8KAAAAgABBAAAAAwAAAAAApQ8MAAAAAAAA CC4AAAAHAAAAAACpDwoAAAAHAAAAAAAECAkEQACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQA AAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABA AkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSSAgAADwAA8IoCAAAAAAbweAEAABy0 AAAuAAAAgwAAAAgAAAAAAAAABwAAAAIAAAAJAAAAAwAAABsAAAAAAAAACAAAAAAAAAAIAAAAAAAA AAYAAAAAAAAABgAAAAAAAAAIAAAAAAAAAAoAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAA FAAAAAAAAAAVAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAQ AAAAAAAAABAAAAAAAAAACwAAAAAAAAAMAAAAAAAAADIAAAAAAAAAMQAAAAAAAAANAAAAAAAAABAA AAAAAAAACwAAAAAAAAANAAAAAAAAAA4AAAAAAAAADQAAAAAAAAAKAAAAAAAAAAoAAAAiAAAACwAA ACMAAAALAAAAAAAAAAQAAAAAAAAABAAAACYAAAAbAAAAAAAAABgAAAAAAAAABAAAACkAAAAeAAAA AAAAAAQAAAArAAAAGQAAAAAAAAAEAAAALQAAABwAAAAfAAHwLAAAAGIAB/AkAAAABgbC4XgVSvjp jXtoAv9fjTPz/wDm1AAAIAAAAAAAAAAAAAAAowEL8JwAAACBAJBfAQCCANC2AACDAJBfAQCEANC2 AACFAAAAAACHAAAAAACIAAAAAAC/AAAAAgCAAQAAAACBAQUAAAiCAQAAAQCDAQAAAAiEAQAAAQCG QQAAAAC/ARAAEADAAQEAAAjBAQAAAQDCAf///wDEAQAAAADFQQAAAADLATUlAADNAQAAAADOAQAA AADXAQIAAAD/AQgACAABAgIAAAgTACLxBgAAAL8BAAAgABAAGvEEAAAA/zMAAEAAHvEQAAAABAAA CAEAAAgCAAAI9wAAEB8A8A84AAAAAADzAxQAAAAFAAAABAAAAAAAAAAWAACAAAAAAAAA8wMUAAAA BgAAAAQAAAAAAAAAFwAAgAAAAAAPANAHMwEAAB8AFAQcAAAAAAAVBBQAAAC6k7D2AMqaO60HlMcA ypo7AQEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEwAAABkAAAATAAAAGQAAAAAAAAAaBv/ BgiEEwB4OgswAAAAAAAAAACg////7P7//wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAA QAsAAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAANIQTABL0CjBolhMACFnyBwAAAAAA AAAAAAAAAAAAAAAAARMAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAA8AiBM4AAAADwCKEzAA AAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQIAAAAcLUAAHC1AAAPAPAPjAMA AAAA8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPLQAAAFJlc3BvbnNp bGJlIFBlZXIoUlApIFJlcGxpY2F0aW9uC2luIERIVCBsZXZlbAAAoQ8UAAAALgAAAAAAAAAAAC4A AAAAAAIAJAAQAJ8PBAAAAAUAAAAAAKgPJQAAAFNvbmcgWW9uZ2NoYW8NKG1lbG9keXNvbmdAaHVh d2VpLmNvbSkAAPMDFAAAAAQAAAAEAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDyMAAABT dGVwMTogQ2hvb3NlIGxvY2F0aW9uIHRvIHJlcGxpY2F0ZRAAnw8EAAAAAQAAAAAAqA8BAAAAIAAA oQ8UAAAAAgAAAAAAAQAAAA4AAgAAAAAAAAAAAPMDFAAAAAcAAAAEAAAAAgAAAAMBAAAAAAAAAACf DwQAAAAAAAAAAACoDx8AAABTdGVwMjogd2hlbiByZXBsaWNhIG5vZGVzIGZhaWwgEACfDwQAAAAB AAAAAACoDwEAAAAgAAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACQAAAAQAAAAC AAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIgAAAFN0ZXAzOiB3aGVuIHJlc3BvbnNpYmxlIHBl ZXIgZmFpbHMQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAA AADzAxQAAAALAAAABAAAAAIAAAAKAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAAU3RlcDQ6IHdo ZW4gdGhlIFJQIGNoYW5nZXMgZ3JhY2VmdWxseQAAoQ8UAAAAJgAAAAAAAAAAACYAAAAAAAIAIAAQ AJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADzAxQAAAAK AAAABAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA80AAAAU3RlcDU6IGhhbmRsZSByZXF1 ZXN0cyB3aGVuIHJlc3BvbnNpYmxlIHBlZXIgaXMgYnVzeQAAoQ8UAAAANQAAAAAAAAAAADUAAAAA AAIAIAAQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADq AwAAAAAPAO4DWA4AAAIA7wMYAAAAAQAAAA0OAAAAAAAAFgAAgAAAAAAHAAswDwAMBG8NAAAPAALw Zw0AANACCPAIAAAAFgAAABu0AAAPAAPw/wwAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAAtAAABQAAAA8ABPBmAAAAMgAK8AgAAAACtAAAAAoAAIMAC/AwAAAAhQACAAAA hwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAYAAA ABDwCAAAAPUFKgTOEXYODwAE8H4AAAASAArwCAAAAAO0AAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAA BACAALxz6gm/AQAAAQD/AQAAAQABAwaIAACIAwAAAAAAABDwCAAAAL4AXwNeFY4DDwAR8BAAAAAA AMMLCAAAAAAAAAANAOoJDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwfgAAABIACvAIAAAABLQAACAC AABzAAvwKgAAAAQAAAAAAH8AAAAEAIAA3HjqCb8BAAABAP8BAAABAAEDB4gAAIgDAAAAAAAAEPAI AAAAfwRfA14Vnw4PABHwEAAAAAAAwwsIAAAAAQAAAA4A6gkPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBUAAAAsgQK8AgAAAAFtAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2E hTV1EYEoABpZklpTTykAAAAAABDwCAAAALEMBg1TD8QODwAE8FQAAACyBArwCAAAAAa0AAAACgAA QwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAI AAAAkApjELASowwPAATwVAAAALIECvAIAAAAB7QAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXB FAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABtBQYNUw+ABw8ABPBUAAAAsgQK 8AgAAAAItAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZ klpTTykAAAAAABDwCAAAABIFSgaXCCUHDwAE8FQAAACyBArwCAAAAAm0AAAACgAAQwAL8CwAAAB/ AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAAywgZA2YF 3goPAATwVAAAALIECvAIAAAACrQAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAA AIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABWDJUF4gdpDg8ABPDDAAAAogwK8AgAAAAMtAAA AAoAAOMAC/BUAAAAgABsxMwIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwAC AAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDw CAAAAD8KWxMvFCYLDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEEAAKEPFAAAAAIAAAAAAAAA AAACAAAAAAABAAMADwAE8MMAAACiDArwCAAAAA20AAAACgAA4wAL8FQAAACAAMzTzAiBAJBfAQCC ANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAign+AdMCcQoPAA3wMQAAAAAAnw8E AAAABAAAAAAAqA8BAAAAQgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAEAAwAPAATwxAAAAKIMCvAI AAAADrQAAAAKAADjAAvwVAAAAIAADFfMCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcA BgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEA ACAAAAAQ8AgAAACKBLsN6A5xBQ8ADfAyAAAAAACfDwQAAAAEAAAAAACoDwIAAABSUAAAoQ8UAAAA AwAAAAAAAAAAAAMAAAAAAAEAAwAPAATwzQAAAKIMCvAIAAAAD7QAAAAKAADjAAvwVAAAAIAAgLfM CIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8B AAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAADLCBAIIwyyCQ8ADfA7 AAAAAACfDwQAAAAEAAAAAACoDwsAAABtYWludGVuYW5jZQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAA AAEAAwAPAATwVAAAALIECvAIAAAAE7QAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYB AQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAACqBgkQVhK9CA8ABPB2AAAAQgEK8AgAAAAU tAAAgAoAANMAC/BOAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADoB+8FCRA2Cg8ABPDS AAAAogwK8AgAAAAVtAAAAAoAAOMAC/BUAAAAgAAgVMwIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAA hQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi 8QYAAAC/AQAAIAAAABDwCAAAACwGHRLiFcAHDwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKgPEAAAAE5l dyBSUCBmb3IgDUtleU0AAKEPFAAAABEAAAAAAAAAAAARAAAAAAABAAMADwAE8HYAAABCAQrwCAAA ABa0AACACgAA0wAL8E4AAACBAJBfAQCCANC2AACDAJBfAQCEANC2AAC/AAAAAgBEAQQAAAB/AQAA AQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAJ0IoRGhEb4KDwAE 8GQBAACiDArwCAAAABi0AAAACgAAwwAL8EgAAACAABizzAiBAJBfAQCCANC2AACDAJBfAQCEANC2 AAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAg AAAAEPAIAAAAgw5qAYAWxBAPAA3w3gAAAAAAnw8EAAAABAAAAAAAqA+uAAAARHVlIHRvIG92ZXJs YXkgdG9wb2xvZ3kgY2hhbmdlcywgdGhlIHJlcG9uc2libGUgcGVlciBtYXkgY2hhbmdlLCBSUCB0 cmFuc2ZlciBrZXlNL3ZhbHVlIHRvIGl0cyBuZXcgcmVzcG9uc2libGUgcGVlciBhbmQgaGFuZCBv dmUgdGhlIG1hbmFnZW1lbnQgb2YgcmVwbGljYXRpb24gZm9yIGtleU0gdG8gaXQgAAChDxQAAACv AAAAAAAAAAAArwAAAAAAAQADAA8ABPBwAAAAQgEK8AgAAAAZtAAAAAoAAMMAC/BIAAAAgQCQXwEA ggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEAvwEAABAAwAH/zAAA0QEBAAAA/wEY ABgAAQICAAAIAAAQ8AgAAABQBiYPvhAyBw8ABPDNAAAAogwK8AgAAAAatAAAAAoAAOMAC/BUAAAA gAB87e8HgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAIAJ2w/uE2cK DwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAG1haW50ZW5hbmNlAAChDxQAAAAMAAAAAAAAAAAA DAAAAAAAAQADAA8ABPADAQAAogwK8AgAAAAbtAAAAAoAAOMAC/BUAAAAgAB83+8HgQCQXwEAggDQ tgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI /wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAF0EUw/iE2MGDwAN8HEAAAAAAJ8PBAAA AAQAAAAAAKgPPwAAAEhhbmRvdmVyIGtleU0vdmFsdWUNcGFpciBhbmQgcmVwbGljYSANTWFuYWdl bWVudCB0byANdGhlIE5ldyBSUAAAoQ8WAAAAQAAAAAAAAAAAAEAAAAAAAAMAAwAMAA8ABPBIAAAA EgAK8AgAAAABtAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEA AAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8A iBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAJjbI AUDRHzoAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAOoJ /////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchcQAAAAAQAQAM6FAAALABAA BZAAAAAA9Q8cAAAACgEAAKQZAAOqhQAAZZ4AAAEAAAALAAAAAQDFMQ8A6AMvCgAAAQDpAygAAACA FgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyA0YCAAAvAMgPDAAAADAA 0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABBAHIAaQBhAGwAAABuAGcAcwAAAFIAbwBtAGEAbgAA AGiWEwBolhMALFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAAAEABAAtw9EAAAAi1tTTwAAYQBsAAAA bgBnAHMAAABSAG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVB4YABAAg ALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMTAHg6 CzDwgxMAAAAAAA8A1QcAAAYSMAC3D0QAAABWAGUAcgBkAGEAbgBhAAAAdwAgAFIAbwBtAGEAbgAA AGiWEwBolhMALFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAAAEIkAAtw9EAAAAVwBpAG4AZwBkAGkA bgBnAHMAAABSAG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVBwIABgIA AKQPCgAAAIAAQQAAAAMAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAAABAgJBEAA ow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAAAQAA AP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAA AAAPAAsEkgIAAA8AAPCKAgAAAAAG8HgBAAActAAALgAAAIMAAAAIAAAAAAAAAAcAAAACAAAACQAA AAMAAAAbAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAKAAAA AAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAABQAAAAAAAAAFQAAAAAAAAAHAAAAAAAAAAcAAAAA AAAABwAAAAAAAAAIAAAAAAAAAAcAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADAAAAAAA AAAyAAAAAAAAADEAAAAAAAAADQAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADQAAAAAAAAAOAAAAAAAA AA0AAAAAAAAACgAAAAAAAAAKAAAAIgAAAAsAAAAjAAAACwAAAAAAAAAEAAAAAAAAAAQAAAAmAAAA GwAAAAAAAAAYAAAAAAAAAAQAAAApAAAAHgAAAAAAAAAEAAAAKwAAABkAAAAAAAAABAAAAC0AAAAc AAAAHwAB8CwAAABiAAfwJAAAAAYGwuF4FUr46Y17aAL/X40z8/8A5tQAACAAAAAAAAAAAAAAAKMB C/CcAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAIAgAEA AAAAgQEFAAAIggEAAAEAgwEAAAAIhAEAAAEAhkEAAAAAvwEQABAAwAEBAAAIwQEAAAEAwgH///8A xAEAAAAAxUEAAAAAywE1JQAAzQEAAAAAzgEAAAAA1wECAAAA/wEIAAgAAQICAAAIEwAi8QYAAAC/ AQAAIAAQABrxBAAAAP8zAABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAA BQAAAAQAAAAAAAAAFgAAgAAAAAAAAPMDFAAAAAYAAAAEAAAAAAAAABcAAIAAAAAADwDQBzMBAAAf ABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9 AzQAAABMAAAAZAAAAEwAAABkAAAAAAAAAGgb/wYIhBMAeDoLMAAAAAAAAAAAoP///+z+//8BABMA cAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABk AAAAZAAAADSEEwAS9AowaJYTAAhZ8gcAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwA AAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACL ExAAAAAAAA0ECAAAAHC1AABwtQAADwDwD4wDAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAA AACfDwQAAAAGAAAAAACoDy0AAABSZXNwb25zaWxiZSBQZWVyKFJQKSBSZXBsaWNhdGlvbgtpbiBE SFQgbGV2ZWwAAKEPFAAAAC4AAAAAAAAAAAAuAAAAAAACACQAEACfDwQAAAAFAAAAAACoDyUAAABT b25nIFlvbmdjaGFvDShtZWxvZHlzb25nQGh1YXdlaS5jb20pAADzAxQAAAAEAAAABAAAAAIAAAAB AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8jAAAAU3RlcDE6IENob29zZSBsb2NhdGlvbiB0byByZXBs aWNhdGUQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADz AxQAAAAHAAAABAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAU3RlcDI6IHdoZW4g cmVwbGljYSBub2RlcyBmYWlsIBAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8UAAAAAgAAAAAAAQAA AA4AAgAAAAAAAAAAAPMDFAAAAAkAAAAEAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDyIA AABTdGVwMzogd2hlbiByZXNwb25zaWJsZSBwZWVyIGZhaWxzEACfDwQAAAABAAAAAACoDwEAAAAg AAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACwAAAAQAAAACAAAACgEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPJQAAAFN0ZXA0OiB3aGVuIHRoZSBSUCBjaGFuZ2VzIGdyYWNlZnVsbHkA AKEPFAAAACYAAAAAAAAAAAAmAAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAAC AAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACgAAAAQAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPNAAAAFN0ZXA1OiBoYW5kbGUgcmVxdWVzdHMgd2hlbiByZXNwb25zaWJsZSBwZWVyIGlz IGJ1c3kAAKEPFAAAADUAAAAAAAAAAAA1AAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAACh DxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA6gMAAAAADwDuA1kOAAACAO8DGAAAAAEAAAANDgAA AAAAABYAAIAAAAAABwALMA8ADARwDQAADwAC8GgNAADQAgjwCAAAABYAAAAbtAAADwAD8AANAAAP AATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAALQAAAUAAAAPAATwZgAAADIA CvAIAAAAArQAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BCAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAQ8AgAAAD1BSoEzhF2Dg8ABPB+AAAAEgAK8AgA AAADtAAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgAC8c+oJvwEAAAEA/wEAAAEAAQMGiAAAiAMA AAAAAAAQ8AgAAAC+AF8DXhWOAw8AEfAQAAAAAADDCwgAAAAAAAAADQDqCQ8ADfAMAAAAAACeDwQA AAAAAAAADwAE8H4AAAASAArwCAAAAAS0AAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACAANx46gm/ AQAAAQD/AQAAAQABAweIAACIAwAAAAAAABDwCAAAAH8EXwNeFZ8ODwAR8BAAAAAAAMMLCAAAAAEA AAAOAOoJDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwVAAAALIECvAIAAAABbQAAAAKAABDAAvwLAAA AH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAACxDAYN Uw/EDg8ABPBUAAAAsgQK8AgAAAAGtAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEB AAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAAJAKYxCwEqMMDwAE8FQAAACyBArwCAAAAAe0 AAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAA AAAAEPAIAAAAbQUGDVMPgAcPAATwVAAAALIECvAIAAAACLQAAAAKAABDAAvwLAAAAH8AgACAAARB AQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAASBUoGlwglBw8ABPBU AAAAsgQK8AgAAAAJtAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1 EYEoABpZklpTTykAAAAAABDwCAAAAMsIGQNmBd4KDwAE8FQAAACyBArwCAAAAAq0AAAACgAAQwAL 8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAA VgyVBeIHaQ4PAATwwwAAAKIMCvAIAAAADLQAAAAKAADjAAvwVAAAAIAAbMTMCIEAkF8BAIIA0LYA AIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8B AAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAAA/ClsTLxQmCw8ADfAxAAAAAACfDwQAAAAE AAAAAACoDwEAAABBAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAQADAA8ABPDDAAAAogwK8AgAAAAN tAAAAAoAAOMAC/BUAAAAgADM08wIgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAA vwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAA ABDwCAAAAIoJ/gHTAnEKDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEIAAKEPFAAAAAIAAAAA AAAAAAACAAAAAAABAAMADwAE8MQAAACiDArwCAAAAA60AAAACgAA4wAL8FQAAACAAAxXzAiBAJBf AQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAigS7DegOcQUPAA3wMgAAAAAA nw8EAAAABAAAAAAAqA8CAAAAUlAAAKEPFAAAAAMAAAAAAAAAAAADAAAAAAABAAMADwAE8M0AAACi DArwCAAAAA+0AAAACgAA4wAL8FQAAACAAIC3zAiBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIA AACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAA AL8BAAAgAAAAEPAIAAAAywgQCCMMsgkPAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8LAAAAbWFpbnRl bmFuY2UAAKEPFAAAAAwAAAAAAAAAAAAMAAAAAAABAAMADwAE8FQAAACyBArwCAAAABO0AAAACgAA QwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAI AAAAqgYJEFYSvQgPAATwdgAAAEIBCvAIAAAAFLQAAIAKAADTAAvwTgAAAIEAkF8BAIIA0LYAAIMA kF8BAIQA0LYAAL8AAAACAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNABAQAAANEBAQAAAP8BGAAY AAECAgAACAAAEPAIAAAA6AfvBQkQNgoPAATw0gAAAKIMCvAIAAAAFbQAAAAKAADjAAvwVAAAAIAA IFTMCIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAAAsBh0S4hXABw8A DfBAAAAAAACfDwQAAAAEAAAAAACoDxAAAABOZXcgUlAgZm9yIA1LZXlNAAChDxQAAAARAAAAAAAA AAAAEQAAAAAAAQADAA8ABPB2AAAAQgEK8AgAAAAWtAAAgAoAANMACwEAAAACAAAAAwAAAAQAAAAF AAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAA ACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+ AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwA AABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAA AFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAA aQAAAGoAAAD+////bAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3 AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUA AACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAA AJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAA ogAAAL8AAACkAAAA/v///6YAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACw AAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAAM8AAAD9/////f///74A AAD+////wAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAKUAAAD+////zAAA AM0AAADOAAAAowAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA 2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADp AAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA/v////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////////// AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAQQT/zWDbIAcsAAADACgAAAAAAAFAAaQBj AHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIB/////wIAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AObUAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAqAAAAMgAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAAFAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkBwAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQA IABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAawAAAIP+AAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAA ADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdAAAA GAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAygAAACAFgAA4BAAAOAQAACAFgAA BQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyA0YCAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8 AQAAAAC3D0QAAABBAHIAaQBhAGwAAABuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMALFnyB/CD EwB4Ogsw8IMTAAAAAAAPANUHAAAEABAAtw9EAAAAi1tTTwAAYQBsAAAAbgBnAHMAAABSAG8AbQBh AG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVB4YABAAgALcPRAAAAFQAaQBtAGUA cwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMTAHg6CzDwgxMAAAAAAA8A1QcA AAYSMAC3D0QAAABWAGUAcgBkAGEAbgBhAAAAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMALFnyB/CD EwB4Ogsw8IMTAAAAAAAPANUHAAAEIkAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAABSAG8AbQBh AG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVBwIABgIAAKQPCgAAAIAAQQAAAAMA AAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAAABAgJBEAAow9uAAAABQD//T8AAAAi IAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAAAQAAAP//EgAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEkgIAAA8AAPCK AgAAAAAG8HgBAAActAAALgAAAIMAAAAIAAAAAAAAAAcAAAACAAAACQAAAAMAAAAbAAAAAAAAAAgA AAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAKAAAAAAAAAAYAAAAAAAAABgAA AAAAAAAEAAAAAAAAABQAAAAAAAAAFQAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAIAAAA AAAAAAcAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADAAAAAAAAAAyAAAAAAAAADEAAAAA AAAADQAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADQAAAAAAAAAOAAAAAAAAAA0AAAAAAAAACgAAAAAA AAAKAAAAIgAAAAsAAAAjAAAACwAAAAAAAAAEAAAAAAAAAAQAAAAmAAAAGwAAAAAAAAAYAAAAAAAA AAQAAAApAAAAHgAAAAAAAAAEAAAAKwAAABkAAAAAAAAABAAAAC0AAAAcAAAAHwAB8CwAAABiAAfw JAAAAAYGwuF4FUr46Y17aAL/X40z8/8A5tQAACAAAAAAAAAAAAAAAKMBC/CcAAAAgQCQXwEAggDQ tgAAgwCQXwEAhADQtgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAIAgAEAAAAAgQEFAAAIggEAAAEA gwEAAAAIhAEAAAEAhkEAAAAAvwEQABAAwAEBAAAIwQEAAAEAwgH///8AxAEAAAAAxUEAAAAAywE1 JQAAzQEAAAAAzgEAAAAA1wECAAAA/wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAQABrxBAAAAP8z AABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAABQAAAAQAAAAAAAAAFgAA gAAAAAAAAPMDFAAAAAYAAAAEAAAAAAAAABcAAIAAAAAADwDQBzMBAAAfABQEHAAAAAAAFQQUAAAA upOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABMAAAAZAAAAEwA AABkAAAAAAAAAGgb/wYIhBMAeDoLMAAAAAAAAAAApv///+z+//8BABMAcAD7AwgAAAAAAAAAcAgA AHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAADSEEwAS9Aow aJYTAAhZ8gcAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAP AIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAA0ECAAAAHC1 AABwtQAADwDwD4wDAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACo Dy0AAABSZXNwb25zaWxiZSBQZWVyKFJQKSBSZXBsaWNhdGlvbgtpbiBESFQgbGV2ZWwAAKEPFAAA AC4AAAAAAAAAAAAuAAAAAAACACQAEACfDwQAAAAFAAAAAACoDyUAAABTb25nIFlvbmdjaGFvDSht ZWxvZHlzb25nQGh1YXdlaS5jb20pAADzAxQAAAAEAAAABAAAAAIAAAABAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8jAAAAU3RlcDE6IENob29zZSBsb2NhdGlvbiB0byByZXBsaWNhdGUQAJ8PBAAAAAEA AAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADzAxQAAAAHAAAABAAAAAIA AAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAU3RlcDI6IHdoZW4gcmVwbGljYSBub2RlcyBm YWlsIBAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8UAAAAAgAAAAAAAQAAAA4AAgAAAAAAAAAAAPMD FAAAAAkAAAAEAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDyIAAABTdGVwMzogd2hlbiBy ZXNwb25zaWJsZSBwZWVyIGZhaWxzEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAACAAAAAAAB AAAADgACAAAAAAAAAAAA8wMUAAAACwAAAAQAAAACAAAACgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP JQAAAFN0ZXA0OiB3aGVuIHRoZSBSUCBjaGFuZ2VzIGdyYWNlZnVsbHkAAKEPFAAAACYAAAAAAAAA AAAmAAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAACAAAAAAABAAAADgACAAAA AAAAAAAA8wMUAAAACgAAAAQAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPNAAAAFN0ZXA1 OiBoYW5kbGUgcmVxdWVzdHMgd2hlbiByZXNwb25zaWJsZSBwZWVyIGlzIGJ1c3kAAKEPFAAAADUA AAAAAAAAAAA1AAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAACAAAAAAABAAAA DgACAAAAAAAAAAAA6gMAAAAADwDuA14LAAACAO8DGAAAAAEAAAANDgAAAAAAABYAAIAAAAAABwAL MA8ADAR1CgAADwAC8G0KAAAwAAjwCAAAABIAAAAaDAAADwAD8O0JAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAwAAAUAAAAPAATwZgAAADIACvAIAAAADgwAAAAKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACBMA IvEGAAAAvwEAAGAAAAAQ8AgAAAD1BSoEzhF2Dg8ABPB4AAAAEgAK8AgAAAACDAAAIAIAAGMAC/Ak AAAABAAAAAAAfwAAAAQAgACQR/8GvwEAAAEA/wEAAAEAAQMGiAAAAAAQ8AgAAAC+AF8DXhWOAw8A EfAQAAAAAADDCwgAAAAAAAAADQD/Bg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAA AAMMAAAgAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAAHDI/wa/AQAAAQD/AQAAAQABAweIAAAAABDw CAAAAH8EXwNeFZ8ODwAR8BAAAAAAAMMLCAAAAAEAAAAOAP8GDwAN8AwAAAAAAJ4PBAAAAAEAAAAP AATwVAAAALIECvAIAAAACAwAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWN hIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABmDQYNUw95Dw8ABPBUAAAAsgQK8AgAAAAJDAAAAAoA AEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDw CAAAACUJvhALEzgLDwAE8FQAAACyBArwCAAAAAoMAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAF wRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAAbQUGDVMPgAcPAATwVAAAALIE CvAIAAAACwwAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAa WZJaU08pAAAAAAAQ8AgAAAASBUoGlwglBw8ABPBUAAAAsgQK8AgAAAAMDAAAAAoAAEMAC/AsAAAA fwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpTTykAAAAAABDwCAAAAMsIGQNm Bd4KDwAE8FQAAACyBArwCAAAAA0MAAAACgAAQwAL8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEA AACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAACw2VBeIHHg8PAATwBQEAAPIDCvAIAAAADwwA AAAKAAATAQvwZgAAAH8AAACAAIAAJFDlCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAL8AAAACAEcB sPT//0gBcD8AAIEBBQAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACD8DAAAQAH8DAAAM ABMAIvEGAAAAvwEAAGAAAAAQ8AgAAAACBPIPgBY0Bw8ADfBhAAAAAACfDwQAAAAEAAAAAACoDy8A AABDaG9vc2UgcGVlciBBLCBCIHRvIHJlcGxpY2F0ZSBhIGtleU0vdmFsdWUgcGFpcgAAoQ8WAAAA MAAAAAAAAAgAAAEAMAAAAAAAAQADAA8ABPB2AAAAQgEK8AgAAAAQDAAAQAoAANMAC/BOAAAAgQCQ XwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0AEBAAAA 0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAAAyB2cFBg0ICg8ABPB2AAAAQgEK8AgAAAARDAAAAAoA ANMAC/BOAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAI0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABgB+gNGRGuCQ8ABPDDAAAAogwK 8AgAAAAUDAAAAAoAAOMAC/BUAAAAgACMfOAJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAA hwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/ AQAAIAAAABDwCAAAAD8KWxMvFCYLDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEEAAKEPFAAA AAIAAAAAAAAAAAACAAAAAAABAAMADwAE8MMAAACiDArwCAAAABUMAAAACgAA4wAL8FQAAACAAJSj 4AmBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/ AQAAEADAAQEAAAj/AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAign+AdMCcQoPAA3w MQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAQgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAEAAwAPAATw 1gAAAKIMCvAIAAAAFgwAAAAKAADjAAvwVAAAAIAAlILjCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYA AIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMA IvEGAAAAvwEAACAAAAAQ8AgAAACKBJsLPhAeBg8ADfBEAAAAAACfDwQAAAAEAAAAAACoDxQAAABS UChyZXNwb25zaWJsZQ1wZWVyKQAAoQ8UAAAAFQAAAAAAAAAAABUAAAAAAAEAAwAPAATwzQAAAKIM CvAIAAAAFwwAAAAKAADjAAvwVAAAAIAAwDTpCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAA AIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAA vwEAACAAAAAQ8AgAAAB5CPQGBwtgCQ8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABtYWludGVu YW5jZQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAEAAwAPAATwzQAAAKIMCvAIAAAAGAwAAAAKAADj AAvwVAAAAIAA0JLgCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEB BQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAABD CDMNRhEqCQ8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABtYWludGVuYW5jZQAAoQ8UAAAADAAA AAAAAAAAAAwAAAAAAAEAAwAPAATwSAAAABIACvAIAAAAAQwAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABAB8ABfAQAAAAAAAX8AgAAAAC AAAADwwAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8A ihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAACY2yAFA0R86AAAA KwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADjCf////8SAAAA DwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXEAAAAAEAEAD1bwAABAAQACx6AAAAAPUP HAAAAAEBAACkGQAD0W8AAJKFAAABAAAACwAAAAEAxTEPAOgDLwoAAAEA6QMoAAAAgBYAAOAQAADg EAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAA CQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAX AAAAGAAAABkAAAAaAAAAGwAAABwAAAD+////HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUA AAAmAAAAJwAAACgAAAApAAAA/v////7///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5 T2gQq5EIACsns9kwAAAA9AYAAAwAAAABAAAAaAAAAAIAAABwAAAABAAAAJgAAAAHAAAAqAAAAAgA AAC4AAAACQAAAMgAAAASAAAA1AAAAAoAAAD4AAAADAAAAAQBAAANAAAAEAEAAA8AAAAcAQAAEQAA ACQBAAACAAAAqAMAAB4AAAAgAAAAUmVzcG9uc2lsYmUgUGVlciBSZXBsaWNhdGlvbgAAAAAeAAAA CAAAAHM2NDA4MQAAHgAAAAgAAABFY2xpcHNlAB4AAAAIAAAAczY0MDgxAAAeAAAABAAAADM1AAAe AAAAHAAAAE1pY3Jvc29mdCBPZmZpY2UgUG93ZXJQb2ludABAAAAAYPvYpzIAAABAAAAAUEjjOiY2 yAFAAAAAIBU481g2yAEDAAAAzwAAAEcAAADIBQAA/////wMAAAAIAIkQZwwAAAEACQAAA9wCAAAH ADcAAAAAAAQAAAADAQgABQAAAAsCAAAAAAUAAAAMAnkAoQADAAAAHgAHAAAA/AIAAP///wAAAAQA AAAtAQAACAAAAPoCBQAAAAAA////AAQAAAAtAQEADgAAACQDBQD///////94AKAAeACgAP////// /wgAAAD6AgAAAAAAAAAAAAAEAAAALQECAAcAAAD8AgAA////AAAABAAAAC0BAwAEAAAAJwH//wMA AAAeAAgAAAD6AgAAAQAAAAAAAAAEAAAALQEEAAcAAAD8AgEAAAAAAAAABAAAAC0BBQAIAAAAJQMC ABkALACYACwABAAAAC0BAgAEAAAALQEDAAQAAADwAQQABAAAACcB//8EAAAA8AEAAAMAAAAeAAcA AAD8AgAAmczMAAAABAAAAC0BAAAEAAAABgEBAAQAAAAtAQEAMgAAACQDFwAAABoABAAcAAgAHwAL ACIADgAmABAAKgASAC4AEwAzABQAOAATADwAEgBBABAARQAOAEkACwBNAAgAUAAEAFMAAABVAAAA VQAAAFUAAAAaAAAAGgAAABoAAAAaAAQAAAAtAQIABAAAAAYBAQAEAAAALQEDAAQAAAAnAf//BAAA APABAAADAAAAHgAHAAAA/AIAAABmZgAAAAQAAAAtAQAABAAAAAYBAQAEAAAALQEBADIAAAAkAxcA AAAMAAMADgAGABEACAAVAAoAGAAMABwADQAgAA4AJAAOACgADgAsAA0AMAAMADQACgA4AAgAPAAG AD8AAwBCAAAARQAAAEUAAABFAAAADAAAAAwAAAAMAAAADAAEAAAALQECAAQAAAAGAQEABAAAAC0B AwAEAAAAJwH//xwAAAD7Avj/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABAAAAC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAGZmAjcAAAAyCh4AGwAgAAAA UmVzcG9uc2libGUgUGVlcihSUCkgUmVwbGljYXRpb24GAAQABAAEAAUABAAEAAIABAACAAQAAwAF AAQABAADAAMABgAFAAMAAgAGAAQABAACAAIABAAFAAIAAgAEAAQABAAAAC4BAAAcAAAA+wIQAAcA AAAAALwCAAAAhgECAiJTeXN0ZW0AAAAAAAAAAAAAGAAAAAIAAACYC7UJ5AQAAAQAAAAtAQYABAAA APABBAAcAAAA+wL4/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgBmZgIZAAAAMgooABsADAAAAGluIERI VCBsZXZlbAIABAACAAYABgAFAAIAAgAEAAQABAACAAQAAAAuAQAABAAAAC0BBgAEAAAA8AEEABwA AAD7Avr/AAAAAAAAkAEAAAAAAEAAIlZlcmRhbmEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA AC0BBAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhsAAAAyCkQAGwANAAAAU29uZyBZb25nY2hh bwAEAAQABAAEAAIABAAEAAQABAADAAQABAAEAAQAAAAuAQAABAAAAC0BBgAEAAAA8AEEABwAAAD7 Avr/AAAAAAAAkAEAAAAAAEAAIlZlcmRhbmEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B BAAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAioAAAAyCk0AGwAXAAAAKG1lbG9keXNvbmdAaHVh d2VpLmNvbSkAAwAGAAQAAgAEAAQABAADAAQABAAEAAYABAAEAAQABQAEAAIAAgADAAQABgADAAQA AAAuAQAABAAAAC0BBgAEAAAA8AEEAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADoAgAAEAAAAAEA AACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAADQAAAABgAAANgAAAAHAAAA4AAAAAgAAADoAAAACQAA APAAAAAKAAAA+AAAABcAAAAAAQAACwAAAAgBAAAQAAAAEAEAABMAAAAYAQAAFgAAACABAAANAAAA KAEAAAwAAACFAgAAAgAAAKgDAADwTgAAAIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAL8AAAACAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACNABAQAAANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAnQih EaERvgoPAATwZQEAAKIMCvAIAAAAGLQAAAAKAADDAAvwSAAAAIAAGLPMCIEAkF8BAIIA0LYAAIMA kF8BAIQA0LYAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEG AAAAvwEAACAAAAAQ8AgAAACDDmoBgBbEEA8ADfDfAAAAAACfDwQAAAAEAAAAAACoD68AAABEdWUg dG8gb3ZlcmxheSB0b3BvbG9neSBjaGFuZ2VzLCB0aGUgcmVwb25zaWJsZSBwZWVyIG1heSBjaGFu Z2UsIFJQIHRyYW5zZmVycyBrZXlNL3ZhbHVlIHRvIGl0cyBuZXcgcmVzcG9uc2libGUgcGVlciBh bmQgaGFuZCBvdmUgdGhlIG1hbmFnZW1lbnQgb2YgcmVwbGljYXRpb24gZm9yIGtleU0gdG8gaXQg AAChDxQAAACwAAAAAAAAAAAAsAAAAAAAAQADAA8ABPBwAAAAQgEK8AgAAAAZtAAAAAoAAMMAC/BI AAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEAvwEAABAAwAH/zAAA 0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABQBiYPvhAyBw8ABPDNAAAAogwK8AgAAAAatAAAAAoA AOMAC/BUAAAAgAB87e8HgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIA gQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAA AIAJ2w/uE2cKDwAN8DsAAAAAAJ8PBAAAAAQAAAAAAKgPCwAAAG1haW50ZW5hbmNlAAChDxQAAAAM AAAAAAAAAAAADAAAAAAAAQADAA8ABPADAQAAogwK8AgAAAAbtAAAAAoAAOMAC/BUAAAAgAB83+8H gQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEA ABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAF0EUw/iE2MGDwAN8HEA AAAAAJ8PBAAAAAQAAAAAAKgPPwAAAEhhbmRvdmVyIGtleU0vdmFsdWUNcGFpciBhbmQgcmVwbGlj YSANTWFuYWdlbWVudCB0byANdGhlIE5ldyBSUAAAoQ8WAAAAQAAAAAAAAAAAAEAAAAAAAAMAAwAM AA8ABPBIAAAAEgAK8AgAAAABtAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAA mZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA 6y4IAAAAJjbIAUDRHzoAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAA AAAAAAAAAOAJ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAAAAchcQAAAAAQAQ AKGeAAALABAA2KgAAAAA9Q8cAAAACgEAAKQZAAN9ngAAObcAAAEAAAALAAAAAQDFMQ8A6AMvCgAA AQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyA0YCAAAv AMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABBAHIAaQBhAGwAAABuAGcAcwAAAFIA bwBtAGEAbgAAAGiWEwBolhMALFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAAAEABAAtw9EAAAAi1tT TwAAYQBsAAAAbgBnAHMAAABSAG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAA DwDVB4YABAAgALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAs WfIH8IMTAHg6CzDwgxMAAAAAAA8A1QcAAAYSMAC3D0QAAABWAGUAcgBkAGEAbgBhAAAAdwAgAFIA bwBtAGEAbgAAAGiWEwBolhMALFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAAAEIkAAtw9EAAAAVwBp AG4AZwBkAGkAbgBnAHMAAABSAG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAA DwDVBwIABgIAAKQPCgAAAIAAQQAAAAMAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAA AAAABAgJBEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP// 7wAAAAAAAQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAA BQAAgASABAAAAAAPAAsEkgIAAA8AAPCKAgAAAAAG8HgBAAActAAALgAAAIMAAAAIAAAAAAAAAAcA AAACAAAACQAAAAMAAAAbAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAA AAAAAAAKAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAABQAAAAAAAAAFQAAAAAAAAAHAAAA AAAAAAcAAAAAAAAABwAAAAAAAAAIAAAAAAAAAAcAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAsAAAAA AAAADAAAAAAAAAAyAAAAAAAAADEAAAAAAAAADQAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADQAAAAAA AAAOAAAAAAAAAA0AAAAAAAAACgAAAAAAAAAKAAAAIgAAAAsAAAAjAAAACwAAAAAAAAAEAAAAAAAA AAQAAAAmAAAAGwAAAAAAAAAYAAAAAAAAAAQAAAApAAAAHgAAAAAAAAAEAAAAKwAAABkAAAAAAAAA BAAAAC0AAAAcAAAAHwAB8CwAAABiAAfwJAAAAAYGwuF4FUr46Y17aAL/X40z8/8A5tQAACAAAAAA AAAAAAAAAKMBC/CcAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQAAAAAAhwAAAAAAiAAAAAAA vwAAAAIAgAEAAAAAgQEFAAAIggEAAAEAgwEAAAAIhAEAAAEAhkEAAAAAvwEQABAAwAEBAAAIwQEA AAEAwgH///8AxAEAAAAAxUEAAAAAywE1JQAAzQEAAAAAzgEAAAAA1wECAAAA/wEIAAgAAQICAAAI EwAi8QYAAAC/AQAAIAAQABrxBAAAAP8zAABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAA AAAA8wMUAAAABQAAAAQAAAAAAAAAFgAAgAAAAAAAAPMDFAAAAAYAAAAEAAAAAAAAABcAAIAAAAAA DwDQBzMBAAAfABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMD AAAAAAEAAAD9AzQAAABMAAAAZAAAAEwAAABkAAAAAAAAAGgb/wYIhBMAeDoLMAAAAAAAAAAAoP// /+z+//8BABMAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAA ZAAAAGQAAABkAAAAZAAAADSEEwAS9AowaJYTAAhZ8gcAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMU AAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLExAAAAAAAA0ECAAAAHC1AABwtQAADwDwD4wDAAAAAPMDFAAAAAMAAAAAAAAAAgAA AAABAAAAAAAAAACfDwQAAAAGAAAAAACoDy0AAABSZXNwb25zaWJsZSBQZWVyKFJQKSBSZXBsaWNh dGlvbgtpbiBESFQgbGV2ZWwAAKEPFAAAAC4AAAAAAAAAAAAuAAAAAAACACQAEACfDwQAAAAFAAAA AACoDyUAAABTb25nIFlvbmdjaGFvDShtZWxvZHlzb25nQGh1YXdlaS5jb20pAADzAxQAAAAEAAAA BAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8jAAAAU3RlcDE6IENob29zZSBsb2NhdGlv biB0byByZXBsaWNhdGUQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIA AAAAAAAAAADzAxQAAAAHAAAABAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAU3Rl cDI6IHdoZW4gcmVwbGljYSBub2RlcyBmYWlsIBAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8UAAAA AgAAAAAAAQAAAA4AAgAAAAAAAAAAAPMDFAAAAAkAAAAEAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAA AAAAAACoDyIAAABTdGVwMzogd2hlbiByZXNwb25zaWJsZSBwZWVyIGZhaWxzEACfDwQAAAABAAAA AACoDwEAAAAgAAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACwAAAAQAAAACAAAA CgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPJQAAAFN0ZXA0OiB3aGVuIHRoZSBSUCBjaGFuZ2VzIGdy YWNlZnVsbHkAAKEPFAAAACYAAAAAAAAAAAAmAAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAg AAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACgAAAAQAAAACAAAACAEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPNAAAAFN0ZXA1OiBoYW5kbGUgcmVxdWVzdHMgd2hlbiByZXNwb25zaWJs ZSBwZWVyIGlzIGJ1c3kAAKEPFAAAADUAAAAAAAAAAAA1AAAAAAACACAAEACfDwQAAAABAAAAAACo DwEAAAAgAAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA6gMAAAAADwDuAzACAAACAO8DGAAA AAAAAAAPEAAAAAAAABcAAIAAAAAABwALMA8ADASgAQAADwAC8JgBAAAgAAjwCAAAAAMAAAAICAAA DwAD8DABAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgAAAUAAAAP AATweAAAABIACvAIAAAAAggAACACAABjAAvwJAAAAAQAAAAAAH8AAAAEAIAAOMryB78BAAABAP8B AAABAAEDBowAAAAAEPAIAAAAbQKNA10V+wUPABHwEAAAAAAAwwsIAAAAAAAAAA8A8gcPAA3wDAAA AAAAng8EAAAAAAAAAA8ABPB4AAAAEgAK8AgAAAADCAAAIAIAAGMAC/AkAAAABAAAAAAAfwAAAAQA gABQu/IHvwEAAAEA/wEAAAEAAQMHjAAAAAAQ8AgAAABvCI0DXRW/DA8AEfAQAAAAAADDCwgAAAAB AAAAEADyBw8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEIAAAADAAAgwAL8DAA AACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAA AP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAAmNsgBoGOJJAAAchcQAAAAAQAQAHW3AAAD ABAArMEAAAAA9Q8cAAAAAAEAAKQZAANRtwAA5MMAAAEAAAALAAAAAQDFMQ8A6AMvCgAAAQDpAygA AACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyA0YCAAAvAMgPDAAA ADAA0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABBAHIAaQBhAGwAAABuAGcAcwAAAFIAbwBtAGEA bgAAAGiWEwBolhMALFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAAAEABAAtw9EAAAAi1tTTwAAYQBs AAAAbgBnAHMAAABSAG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVB4YA BAAgALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAsWfIH8IMT AHg6CzDwgxMAAAAAAA8A1QcAAAYSMAC3D0QAAABWAGUAcgBkAGEAbgBhAAAAdwAgAFIAbwBtAGEA bgAAAGiWEwBolhMALFnyB/CDEwB4Ogsw8IMTAAAAAAAPANUHAAAEIkAAtw9EAAAAVwBpAG4AZwBk AGkAbgBnAHMAAABSAG8AbQBhAG4AAABolhMAaJYTACxZ8gfwgxMAeDoLMPCDEwAAAAAADwDVBwIA BgIAAKQPCgAAAIAAQQAAAAMAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAAABAgJ BEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA AQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAAAPAAsEkgIAAA8AAPCKAgAAAAAG8HgBAAActAAALgAAAIMAAAAIAAAAAAAAAAcAAAACAAAA CQAAAAMAAAAbAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAK AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAAAAABQAAAAAAAAAFQAAAAAAAAAHAAAAAAAAAAcA AAAAAAAABwAAAAAAAAAIAAAAAAAAAAcAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADAAA AAAAAAAyAAAAAAAAADEAAAAAAAAADQAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADQAAAAAAAAAOAAAA AAAAAA0AAAAAAAAACgAAAAAAAAAKAAAAIgAAAAsAAAAjAAAACwAAAAAAAAAEAAAAAAAAAAQAAAAm AAAAGwAAAAAAAAAYAAAAAAAAAAQAAAApAAAAHgAAAAAAAAAEAAAAKwAAABkAAAAAAAAABAAAAC0A AAAcAAAAHwAB8CwAAABiAAfwJAAAAAYGwuF4FUr46Y17aAL/X40z8/8A5tQAACAAAAAAAAAAAAAA AKMBC/CcAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAIA gAEAAAAAgQEFAAAIggEAAAEAgwEAAAAIhAEAAAEAhkEAAAAAvwEQABAAwAEBAAAIwQEAAAEAwgH/ //8AxAEAAAAAxUEAAAAAywE1JQAAzQEAAAAAzgEAAAAA1wECAAAA/wEIAAgAAQICAAAIEwAi8QYA AAC/AQAAIAAQABrxBAAAAP8zAABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMU AAAABQAAAAQAAAAAAAAAFgAAgAAAAAAAAPMDFAAAAAYAAAAEAAAAAAAAABcAAIAAAAAADwDQBzMB AAAfABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEA AAD9AzQAAABMAAAAZAAAAEwAAABkAAAAAAAAAGgb/wYIhBMAeDoLMAAAAAAAAAAApv///+z+//8B ABMAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQA AABkAAAAZAAAADSEEwAS9AowaJYTAAhZ8gcAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAA BAwAAAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLExAAAAAAAA0ECAAAAHC1AABwtQAADwDwD4wDAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAA AAAAAACfDwQAAAAGAAAAAACoDy0AAABSZXNwb25zaWJsZSBQZWVyKFJQKSBSZXBsaWNhdGlvbgtp biBESFQgbGV2ZWwAAKEPFAAAAC4AAAAAAAAAAAAuAAAAAAACACQAEACfDwQAAAAFAAAAAACoDyUA AABTb25nIFlvbmdjaGFvDShtZWxvZHlzb25nQGh1YXdlaS5jb20pAADzAxQAAAAEAAAABAAAAAIA AAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8jAAAAU3RlcDE6IENob29zZSBsb2NhdGlvbiB0byBy ZXBsaWNhdGUQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAA AADzAxQAAAAHAAAABAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAU3RlcDI6IHdo ZW4gcmVwbGljYSBub2RlcyBmYWlsIBAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8UAAAAAgAAAAAA AQAAAA4AAgAAAAAAAAAAAPMDFAAAAAkAAAAEAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACo DyIAAABTdGVwMzogd2hlbiByZXNwb25zaWJsZSBwZWVyIGZhaWxzEACfDwQAAAABAAAAAACoDwEA AAAgAAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACwAAAAQAAAACAAAACgEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPJQAAAFN0ZXA0OiB3aGVuIHRoZSBSUCBjaGFuZ2VzIGdyYWNlZnVs bHkAAKEPFAAAACYAAAAAAAAAAAAmAAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQA AAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACgAAAAQAAAACAAAACAEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPNAAAAFN0ZXA1OiBoYW5kbGUgcmVxdWVzdHMgd2hlbiByZXNwb25zaWJsZSBwZWVy IGlzIGJ1c3kAAKEPFAAAADUAAAAAAAAAAAA1AAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAg AAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA6gMAAAAAAAByFwgAAAABABAAIMQAAAAA9Q8c AAAAAQEAAKQZAAP8wwAAV84AAAEAAAALAAAADwDFMQ8A6AMvCgAAAQDpAygAAACAFgAA4BAAAOAQ AACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyA0YCAAAvAMgPDAAAADAA0g8EAAAAAAAA AA8A1Qd8AQAAAAC3D0QAAABBAHIAaQBhAGwAAABuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMA CD7qCfCDEwB4Ogsw8IMTAAAAAAAPANUHAAAEABAAtw9EAAAAi1tTTwAAYQBsAAAAbgBnAHMAAABS AG8AbQBhAG4AAABolhMAaJYTAAg+6gnwgxMAeDoLMPCDEwAAAAAADwDVB4YABAAgALcPRAAAAFQA aQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAIPuoJ8IMTAHg6CzDwgxMAAAAA AA8A1QcAAAYSMAC3D0QAAABWAGUAcgBkAGEAbgBhAAAAdwAgAFIAbwBtAGEAbgAAAGiWEwBolhMA CD7qCfCDEwB4Ogsw8IMTAAAAAAAPANUHAAAEIkAAtw9EAAAAVwBpAG4AZwBkAGkAbgBnAHMAAABS AG8AbQBhAG4AAABolhMAaJYTAAg+6gnwgxMAeDoLMPCDEwAAAAAADwDVBwIABgIAAKQPCgAAAIAA QQAAAAMAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAAABAgJBEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAAAQAAAP//EgAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEkgIA AA8AAPCKAgAAAAAG8HgBAAActAAALgAAAIMAAAAIAAAAAAAAAAcAAAACAAAACQAAAAMAAAAbAAAA AAAAAAgAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAKAAAAAAAAAAYAAAAA AAAABgAAAAAAAAAEAAAAAAAAABQAAAAAAAAAFQAAAAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAA AAAIAAAAAAAAAAcAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADAAAAAAAAAAyAAAAAAAA ADEAAAAAAAAADQAAAAAAAAAQAAAAAAAAAAsAAAAAAAAADQAAAAAAAAAOAAAAAAAAAA0AAAAAAAAA CgAAAAAAAAAKAAAAIgAAAAsAAAAjAAAACwAAAAAAAAAEAAAAAAAAAAQAAAAmAAAAGwAAAAAAAAAY AAAAAAAAAAQAAAApAAAAHgAAAAAAAAAEAAAAKwAAABkAAAAAAAAABAAAAC0AAAAcAAAAHwAB8CwA AABiAAfwJAAAAAYGwuF4FUr46Y17aAL/X40z8/8A5tQAACAAAAAAAAAAAAAAAKMBC/CcAAAAgQCQ XwEAggDQtgAAgwCQXwEAhADQtgAAhQAAAAAAhwAAAAAAiAAAAAAAvwAAAAIAgAEAAAAAgQEFAAAI ggEAAAEAgwEAAAAIhAEAAAEAhkEAAAAAvwEQABAAwAEBAAAIwQEAAAEAwgH///8AxAEAAAAAxUEA AAAAywE1JQAAzQEAAAAAzgEAAAAA1wECAAAA/wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAQABrx BAAAAP8zAABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAABQAAAAQAAAAA AAAAFgAAgAAAAAAAAPMDFAAAAAYAAAAEAAAAAAAAABcAAIAAAAAADwDQBzMBAAAfABQEHAAAAAAA FQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABMAAAA ZAAAAEwAAABkAAAAAAAAADw86gkIhBMAeDoLMAAAAAAAAAAApv///+z+//8BABMAcAD7AwgAAAAA AAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAADSE EwAS9AowaJYTAOQ96gkAAAAAAAAAAAAAAAAAAAAAAAETAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAA AAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAA0E CAAAAHC1AABwtQAADwDwD4wDAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAG AAAAAACoDy0AAABSZXNwb25zaWJsZSBQZWVyKFJQKSBSZXBsaWNhdGlvbgtpbiBESFQgbGV2ZWwA AKEPFAAAAC4AAAAAAAAAAAAuAAAAAAACACQAEACfDwQAAAAFAAAAAACoDyUAAABTb25nIFlvbmdj aGFvDShtZWxvZHlzb25nQGh1YXdlaS5jb20pAADzAxQAAAAEAAAABAAAAAIAAAABAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8jAAAAU3RlcDE6IENob29zZSBsb2NhdGlvbiB0byByZXBsaWNhdGUQAJ8P BAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADzAxQAAAAHAAAA BAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8fAAAAU3RlcDI6IHdoZW4gcmVwbGljYSBu b2RlcyBmYWlsIBAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8UAAAAAgAAAAAAAQAAAA4AAgAAAAAA AAAAAPMDFAAAAAkAAAAEAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDyIAAABTdGVwMzog d2hlbiByZXNwb25zaWJsZSBwZWVyIGZhaWxzEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAAC AAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACwAAAAQAAAACAAAACgEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPJQAAAFN0ZXA0OiB3aGVuIHRoZSBSUCBjaGFuZ2VzIGdyYWNlZnVsbHkAAKEPFAAAACYA AAAAAAAAAAAmAAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAACAAAAAAABAAAA DgACAAAAAAAAAAAA8wMUAAAACgAAAAQAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPNAAA AFN0ZXA1OiBoYW5kbGUgcmVxdWVzdHMgd2hlbiByZXNwb25zaWJsZSBwZWVyIGlzIGJ1c3kAAKEP FAAAADUAAAAAAAAAAAA1AAAAAAACACAAEACfDwQAAAABAAAAAACoDwEAAAAgAAChDxQAAAACAAAA AAABAAAADgACAAAAAAAAAAAA6gMAAAAADwDuA0INAAACAO8DGAAAAAEAAAANDgAAAAAAABYAAIAA AAAABwALMA8ADARZDAAADwAC8FEMAACwAgjwCAAAABMAAAAYrAAADwAD8OELAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKwAAAUAAAAPAATwZgAAADIACvAIAAAAAqwA AAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAEC AgAACBMAIvEGAAAAvwEAAGAAAAAQ8AgAAAD1BSoEzhF2Dg8ABPB+AAAAEgAK8AgAAAADrAAAIAIA AHMAC/AqAAAABAAAAAAAfwAAAAQAgACwE+UJvwEAAAEA/wEAAAEAAQMGiAAAiAMAAAAAAAAQ8AgA AAC+AF8DXhWOAw8AEfAQAAAAAADDCwgAAAAAAAAADQDlCQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE 8H4AAAASAArwCAAAAASsAAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACAAIgU5Qm/AQAAAQD/AQAA AQABAweIAACIAwAAAAAAABDwCAAAAH8EXwNeFZ8ODwAR8BAAAAAAAMMLCAAAAAEAAAAOAOUJDwAN 8AwAAAAAAJ4PBAAAAAEAAAAPAATwVAAAALIECvAIAAAABawAAAAKAABDAAvwLAAAAH8AgACAAARB AQAAAAXBFAAAAAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABmDQYNUw95Dw8ABPBU AAAAsgQK8AgAAAAGrAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1 EYEoABpZklpTTykAAAAAABDwCAAAACUJvhALEzgLDwAE8FQAAACyBArwCAAAAAesAAAACgAAQwAL 8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAA bQUGDVMPgAcPAATwVAAAALIECvAIAAAACKwAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAA AAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAASBUoGlwglBw8ABPBUAAAAsgQK8AgA AAAJrAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpT TykAAAAAABDwCAAAAMsIGQNmBd4KDwAE8FQAAACyBArwCAAAAAqsAAAACgAAQwAL8CwAAAB/AIAA gAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAACw2VBeIHHg8P AATwwwAAAKIMCvAIAAAADqwAAAAKAADjAAvwVAAAAIAA1BnlCYEAkF8BAIIA0LYAAIMAkF8BAIQA 0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAA CBMAIvEGAAAAvwEAACAAAAAQ8AgAAAA/ClsTLxQmCw8ADfAxAAAAAACfDwQAAAAEAAAAAACoDwEA AABBAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAQADAA8ABPDDAAAAogwK8AgAAAAPrAAAAAoAAOMA C/BUAAAAgABQHOUJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEF AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAK4J rwGEApUKDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEIAAKEPFAAAAAIAAAAAAAAAAAACAAAA AAABAAMADwAE8MQAAACiDArwCAAAABCsAAAACgAA4wAL8FQAAACAAFgh5QmBAJBfAQCCANC2AACD AJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAA CAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAigS7DegOcQUPAA3wMgAAAAAAnw8EAAAABAAA AAAAqA8CAAAAUlAAAKEPFAAAAAMAAAAAAAAAAAADAAAAAAABAAMADwAE8DIBAAACAArwCAAAABOs AAAACgAAEwIL8PwAAACBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAAAAACHAAAAAACIAAAAAAC/ AAAAAgBCAX4FAABDATMGAABEAQQAAABFwRwAAABGwRQAAAB/AQEAAQCAAQAAAACBAQUAAAiCAQAA AQCDAQAAAAiEAQAAAQCGQQAAAAC/AQAAEADAAQEAAAjBAQAAAQDCAf///wDEAQAAAADFQQAAAADL ATUlAADNAQAAAADOAQAAAADRAQEAAADXAQIAAAD/ARgAGAABAgIAAAgHAAcA8P8AADMGVwBpBK4A oAKYAZgBggKQAN8ERAB+BQAABwAIAAIAAEAArQEgAK0BIACsAIATACLxBgAAAL8BAABgAAAAEPAI AAAA2AZaB9gMCw0PAATw1gAAAKIMCvAIAAAAFKwAAAAKAADjAAvwVAAAAIAAbCTlCYEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAACACdIGTQ1nCg8ADfBEAAAAAACfDwQA AAAEAAAAAACoDxQAAABHZXQgcmVxdWVzdCBmb3IgS2V5TQAAoQ8UAAAAFQAAAAAAAAAAABUAAAAA AAEAAwAPAATwcAAAAEIBCvAIAAAAFawAAAAKAADDAAvwSAAAAIEAkF8BAIIA0LYAAIMAkF8BAIQA 0LYAAL8AAAACAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAECAgAACAAAEPAI AAAAYAdTD0YRrgkPAATw7QAAAKIMCvAIAAAAFqwAAAAKAADjAAvwVAAAAIAAlCDlCYEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAAAAAQ8AgAAACNB3AOChUhCQ8ADfBbAAAAAACfDwQA AAAEAAAAAACoDysAAABSZWxheSB0aGUgcmVxdWVzdCB0byANcmVwbGljYSBub2RlIGZvciBLZXlN AAChDxQAAAAsAAAAAAAAAAAALAAAAAAAAQADAA8ABPDGAAAAogwK8AgAAAAXrAAAAAoAAOMAC/BU AAAAgADIJeUJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIAgQEFAAAI gwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAAAG0FUw8j EVQGDwAN8DQAAAAAAJ8PBAAAAAQAAAAAAKgPBAAAAEJ1c3kAAKEPFAAAAAUAAAAAAAAAAAAFAAAA AAABAAMADwAE8FIBAACiDArwCAAAABisAAAACgAA4wAL8FQAAACAABCe5QmBAJBfAQCCANC2AACD AJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAA CAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAA/g77/5cWkhAPAA3wwAAAAAAAnw8EAAAABAAA AAAAqA+QAAAAV2hlbiB0aGUgcmVzcG9uc2libGUgcGVlciBpcyBidXN5LCBpdCBjYW4gcmVsYXkg cmVxdWVzdHMgb2YgaXRzIHJlc3BvbnNpYmxlIGtleQ10byB0aGUgcmVwbGljYSwgd2hpY2ggY2Fu IHByZXZlbnQgaXRzIGJ1c3kgc3RhdHVzIGdldHRpbmcgd29yc2UuAAChDxQAAACRAAAAAAAAAAAA kQAAAAAAAQADAA8ABPBIAAAAEgAK8AgAAAABrAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEADwAF8AAAAAAQAPAHIAAAAP///wAAAAAA gICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQ AFQAMQAwAAAAixNpAAAAAADrLggAAAAmNsgBQNEfOgAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA6Qn/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8A AisAAAAAAAByFxAAAAABABAAi84AAAoAEADC2AAAAAD1DxwAAAAIAQAApBkAA2fOAAAM5gAAAQAA AAsAAAABAMUxDwDoAy8KAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAA AQAAAAAAAAEPAPIDRgIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAEEAcgBp AGEAbAAAAG4AZwBzAAAAUgBvAG0AYQBuAAAAaJYTAGiWEwAIPuoJ8IMTAHg6CzDwgxMAAAAAAA8A 1QcAAAQAEAC3D0QAAACLW1NPAABhAGwAAABuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMACD7q CfCDEwB4Ogsw8IMTAAAAAAAPANUHhgAEACAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8A bQBhAG4AAABolhMAaJYTAAg+6gnwgxMAeDoLMPCDEwAAAAAADwDVBwAABhIwALcPRAAAAFYAZQBy AGQAYQBuAGEAAAB3ACAAUgBvAG0AYQBuAAAAaJYTAGiWEwAIPuoJ8IMTAHg6CzDwgxMAAAAAAA8A 1QcAAAQiQAC3D0QAAABXAGkAbgBnAGQAaQBuAGcAcwAAAFIAbwBtAGEAbgAAAGiWEwBolhMACD7q CfCDEwB4Ogsw8IMTAAAAAAAPANUHAgAGAgAApA8KAAAAgABBAAAAAwAAAAAApQ8MAAAAAAAACC4A AAAHAAAAAACpDwoAAAAHAAAAAAAECAkEQACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAAAAA AAAAAABAAgAAAAAHAAAA///vAAAAAAABAAAA//8SAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkAC AAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSSAgAADwAA8IoCAAAAAAbweAEAABy0AAAu AAAAhAAAAAgAAAAAAAAABwAAAAIAAAAJAAAAAwAAABsAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAYA AAAAAAAABgAAAAAAAAAIAAAAAAAAAAoAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAAFAAA AAAAAAAVAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAQAAAA AAAAABAAAAAAAAAACwAAAAAAAAAMAAAAAAAAADIAAAAAAAAAMQAAAAAAAAANAAAAAAAAABAAAAAA AAAACwAAAAAAAAANAAAAAAAAAA4AAAAAAAAADQAAAAAAAAAKAAAAAAAAAAoAAAAiAAAACwAAACMA AAALAAAAAAAAAAQAAAAAAAAABAAAACYAAAAbAAAAAAAAABgAAAAAAAAABAAAACkAAAAeAAAAAAAA AAQAAAArAAAAGgAAAAAAAAAEAAAALQAAABwAAAAfAAHwLAAAAGIAB/AkAAAABgbC4XgVSvjpjXto Av9fjTPz/wDm1AAAIAAAAAAAAAAAAAAAowEL8JwAAACBAJBfAQCCANC2AACDAJBfAQCEANC2AACF AAAAAACHAAAAAACIAAAAAAC/AAAAAgCAAQAAAACBAQUAAAiCAQAAAQCDAQAAAAiEAQAAAQCGQQAA AAC/ARAAEADAAQEAAAjBAQAAAQDCAf///wDEAQAAAADFQQAAAADLATUlAADNAQAAAADOAQAAAADX AQIAAAD/AQgACAABAgIAAAgTACLxBgAAAL8BAAAgABAAGvEEAAAA/zMAAEAAHvEQAAAABAAACAEA AAgCAAAI9wAAEB8A8A84AAAAAADzAxQAAAAFAAAABAAAAAAAAAAWAACAAAAAAAAA8wMUAAAABgAA AAQAAAAAAAAAFwAAgAAAAAAPANAHMwEAAB8AFAQcAAAAAAAVBBQAAAC6k7D2AMqaO60HlMcAypo7 AQEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEwAAABkAAAATAAAAGQAAAAAAAAAPDzqCQiE EwB4OgswAAAAAAAAAACm////7P7//wEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsA AB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAANIQTABL0CjBolhMA5D3qCQAAAAAAAAAA AAAAAAAAAAAAARMAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAA8AiBM4AAAADwCKEzAAAAAA ALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQIAAAAcLUAAHC1AAAPAPAPjAMAAAAA 8wMUAAAAAwAAAAAAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPLQAAAFJlc3BvbnNpYmxl IFBlZXIoUlApIFJlcGxpY2F0aW9uC2luIERIVCBsZXZlbAAAoQ8UAAAALgAAAAAAAAAAAC4AAAAA AAIAJAAQAJ8PBAAAAAUAAAAAAKgPJQAAAFNvbmcgWW9uZ2NoYW8NKG1lbG9keXNvbmdAaHVhd2Vp LmNvbSkAAPMDFAAAAAQAAAAEAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDyMAAABTdGVw MTogQ2hvb3NlIGxvY2F0aW9uIHRvIHJlcGxpY2F0ZRAAnw8EAAAAAQAAAAAAqA8BAAAAIAAAoQ8U AAAAAgAAAAAAAQAAAA4AAgAAAAAAAAAAAPMDFAAAAAcAAAAEAAAAAgAAAAMBAAAAAAAAAACfDwQA AAAAAAAAAACoDx8AAABTdGVwMjogd2hlbiByZXBsaWNhIG5vZGVzIGZhaWwgEACfDwQAAAABAAAA AACoDwEAAAAgAAChDxQAAAACAAAAAAABAAAADgACAAAAAAAAAAAA8wMUAAAACQAAAAQAAAACAAAA BgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIgAAAFN0ZXAzOiB3aGVuIHJlc3BvbnNpYmxlIHBlZXIg ZmFpbHMQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADz AxQAAAALAAAABAAAAAIAAAAKAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAAU3RlcDQ6IHdoZW4g dGhlIFJQIGNoYW5nZXMgZ3JhY2VmdWxseQAAoQ8UAAAAJgAAAAAAAAAAACYAAAAAAAIAIAAQAJ8P BAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADzAxQAAAAKAAAA BAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA80AAAAU3RlcDU6IGhhbmRsZSByZXF1ZXN0 cyB3aGVuIHJlc3BvbnNpYmxlIHBlZXIgaXMgYnVzeQAAoQ8UAAAANQAAAAAAAAAAADUAAAAAAAIA IAAQAJ8PBAAAAAEAAAAAAKgPAQAAACAAAKEPFAAAAAIAAAAAAAEAAAAOAAIAAAAAAAAAAADqAwAA AAAPAO4DwA0AAAIA7wMYAAAAAQAAAA0OAAAAAAAAFgAAgAAAAAAHAAswDwAMBNcMAAAPAALwzwwA ALACCPAIAAAAFAAAABmsAAAPAAPwXwwAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAArAAABQAAAA8ABPBmAAAAMgAK8AgAAAACrAAAAAoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAYAAAABDw CAAAAPUFKgTOEXYODwAE8H4AAAASAArwCAAAAAOsAAAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACA ALAT5Qm/AQAAAQD/AQAAAQABAwaIAACIAwAAAAAAABDwCAAAAL4AXwNeFY4DDwAR8BAAAAAAAMML CAAAAAAAAAANAOUJDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwfgAAABIACvAIAAAABKwAACACAABz AAvwKgAAAAQAAAAAAH8AAAAEAIAAiBTlCb8BAAABAP8BAAABAAEDB4gAAIgDAAAAAAAAEPAIAAAA fwRfA14Vnw4PABHwEAAAAAAAwwsIAAAAAQAAAA4A5QkPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBU AAAAsgQK8AgAAAAFrAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1 EYEoABpZklpTTykAAAAAABDwCAAAAGYNBg1TD3kPDwAE8FQAAACyBArwCAAAAAasAAAACgAAQwAL 8CwAAAB/AIAAgAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAA JQm+EAsTOAsPAATwVAAAALIECvAIAAAAB6wAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAA AAYBAQAAAIWNhIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAABtBQYNUw+ABw8ABPBUAAAAsgQK8AgA AAAIrAAAAAoAAEMAC/AsAAAAfwCAAIAABEEBAAAABcEUAAAABgEBAAAAhY2EhTV1EYEoABpZklpT TykAAAAAABDwCAAAABIFSgaXCCUHDwAE8FQAAACyBArwCAAAAAmsAAAACgAAQwAL8CwAAAB/AIAA gAAEQQEAAAAFwRQAAAAGAQEAAACFjYSFNXURgSgAGlmSWlNPKQAAAAAAEPAIAAAAywgZA2YF3goP AATwVAAAALIECvAIAAAACqwAAAAKAABDAAvwLAAAAH8AgACAAARBAQAAAAXBFAAAAAYBAQAAAIWN hIU1dRGBKAAaWZJaU08pAAAAAAAQ8AgAAAALDZUF4gceDw8ABPDDAAAAogwK8AgAAAAOrAAAAAoA AOMAC/BUAAAAgADUGeUJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAAIA gQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/AQAAIAAAABDwCAAA AD8KWxMvFCYLDwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEEAAKEPFAAAAAIAAAAAAAAAAAAC AAAAAAABAAMADwAE8MMAAACiDArwCAAAAA+sAAAACgAA4wAL8FQAAACAAFAc5QmBAJBfAQCCANC2 AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAArgmvAYQClQoPAA3wMQAAAAAAnw8EAAAA BAAAAAAAqA8BAAAAQgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAEAAwAPAATwxAAAAKIMCvAIAAAA EKwAAAAKAADjAAvwVAAAAIAAWCHlCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAA AL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAA AAAQ8AgAAACKBLsN6A5xBQ8ADfAyAAAAAACfDwQAAAAEAAAAAACoDwIAAABSUAAAoQ8UAAAAAwAA AAAAAAAAAAMAAAAAAAEAAwAPAATwMgEAAAIACvAIAAAAE6wAAAAKAAATAgvw/AAAAIEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAAAAAIcAAAAAAIgAAAAAAL8AAAACAEIBfgUAAEMBMwYAAEQBBAAA AEXBHAAAAEbBFAAAAH8BAQABAIABAAAAAIEBBQAACIIBAAABAIMBAAAACIQBAAABAIZBAAAAAL8B AAAQAMABAQAACMEBAAABAMIB////AMQBAAAAAMVBAAAAAMsBNSUAAM0BAAAAAM4BAAAAANEBAQAA ANcBAgAAAP8BGAAYAAECAgAACAcABwDw/wAAMwZXAGkErgCgApgBmAGCApAA3wREAH4FAAAHAAgA AgAAQACtASAArQEgAKwAgBMAIvEGAAAAvwEAAGAAAAAQ8AgAAADYBloH2AwLDQ8ABPDWAAAAogwK 8AgAAAAUrAAAAAoAAOMAC/BUAAAAgABsJOUJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAA hwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/ AQAAIAAAABDwCAAAAIAJ0gZNDWcKDwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAAEdldCByZXF1 ZXN0IGZvciBLZXlNAAChDxQAAAAVAAAAAAAAAAAAFQAAAAAAAQADAA8ABPBwAAAAQgEK8AgAAAAV rAAAAAoAAMMAC/BIAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAvwAAAAIARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABgB1MPRhGuCQ8ABPDtAAAAogwK 8AgAAAAWrAAAAAoAAOMAC/BUAAAAgACUIOUJgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAA hwAGAAAAvwACAAIAgQEFAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIEwAi8QYAAAC/ AQAAIAAAABDwCAAAAI0HcA4KFSEJDwAN8FsAAAAAAJ8PBAAAAAQAAAAAAKgPKwAAAFJlbGF5IHRo ZSByZXF1ZXN0IHRvIA1yZXBsaWNhIG5vZGUgZm9yIEtleU0AAKEPFAAAACwAAAAAAAAAAAAsAAAA AAABAAMADwAE8MYAAACiDArwCAAAABesAAAACgAA4wAL8FQAAACAAMgl5QmBAJBfAQCCANC2AACD AJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIAAgCBAQUAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAA CAABAgIAAAgTACLxBgAAAL8BAAAgAAAAEPAIAAAAbQVTDyMRVAYPAA3wNAAAAAAAnw8EAAAABAAA AAAAqA8EAAAAQnVzeQAAoQ8UAAAABQAAAAAAAAAAAAUAAAAAAAEAAwAPAATwUgEAAKIMCvAIAAAA GKwAAAAKAADjAAvwVAAAAIAAEJ7lCYEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAA AL8AAgACAIEBBQAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACBMAIvEGAAAAvwEAACAA AAAQ8AgAAAD+Dvv/lxaSEA8ADfDAAAAAAACfDwQAAAAEAAAAAACoD5AAAABXaGVuIHRoZSByZXNw b25zaWJsZSBwZWVyIGlzIGJ1c3ksIGl0IGNhbiByZWxheSByZXF1ZXN0cyBvZiBpdHMgcmVzcG9u c2libGUga2V5DXRvIHRoZSByZXBsaWNhLCB3aGljaCBjYW4gcHJldmVudCBpdHMgYnVzeSBzdGF0 dXMgZ2V0dGluZyB3b3JzZS4AAKEPFAAAAJEAAAAAAAAAAACRAAAAAAABAAMADwAE8HYAAABCAQrw CAAAABmsAABACgAA0wAL8E4AAACBAJBfAQCCANC2AACDAJBfAQCEANC2AAC/AAAAAgBEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAH0GOgXYDCUJ DwAE8EgAAAASAArwCAAAAAGsAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAPAAXwAAAAABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg 4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACL E2kAAAAAAOsuCAAAACY2yAFA0R86AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAA AAAAAAAAAAAAAAAAAADmCf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIX EAAAAAEAEABI5gAACgAQAH/wAAAAAPUPHAAAAAgBAACkGQADJOYAAEf+AAABAAAACwAAAAEAxTEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////////// AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAADw19MPWTbIAcsAAAAACwAAAAAAAFAAaQBj AHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIB/////wIAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AObUAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAqAAAAMgAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAAFAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkBwAAAAAAAIEAAACCAAAAgwAAAIQAAACFAAAA hgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACU AAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIA AAC/AAAA//////////+mAAAApwAAAKgAAACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAA ALEAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAAuQAAALoAAADPAAAA/f////////////// /////8AAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADHAAAAyAAAAMkAAAClAAAA/////8wAAADN AAAA+gAAAP/////QAAAA0QAAANIAAADTAAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA2gAAANsA AADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAA AOoAAADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADxAAAA8gAAAPMAAAD0AAAA9QAAAP7////5AAAA /f////7////+////+wAAAPwAAAD+////////////////////AQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAP7///8eAAAAHwAAACAAAAAhAAAAIgAA ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAArAAAA/v////7///////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////9QAG8AdwBlAHIAUABvAGkAbgB0ACAA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGsAAACD/gAAAAAAAAUARABvAGMA dQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4 AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQAAAGAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAJAgAAAAIbAAAAMgpEABsADQAA AFNvbmcgWW9uZ2NoYW8ABAAEAAQABAACAAQABAAEAAQAAwAEAAQABAAEAAAALgEAAAQAAAAtAQYA BAAAAPABBAAcAAAA+wL6/wAAAAAAAJABAAAAAABAACJWZXJkYW5hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAAAtAQQABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIqAAAAMgpNABsAFwAAACht ZWxvZHlzb25nQGh1YXdlaS5jb20pAAMABgAEAAIABAAEAAQAAwAEAAQABAAGAAQABAAEAAUABAAC AAIAAwAEAAYAAwAEAAAALgEAAAQAAAAtAQYABAAAAPABBAADAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5riwDAADoAgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQA AADQAAAABgAAANgAAAAHAAAA4AAAAAgAAADoAAAACQAAAPAAAAAKAAAA+AAAABcAAAAAAQAACwAA AAgBAAAQAAAAEAEAABMAAAAYAQAAFgAAACABAAANAAAAKAEAAAwAAACFAgAAAgAAAKgDAAAeAAAA EAAAAE9uLXNjcmVlbiBTaG93AAAeAAAAIAAAAEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4A AAAAAwAAAIP+AAADAAAAQAAAAAMAAAAGAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAKgZ CwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAMAAAABgAAAEFyaWFsAAUAAADL zszlABAAAABUaW1lcyBOZXcgUm9tYW4ACAAAAFZlcmRhbmEACgAAAFdpbmdkaW5ncwAIAAAARWNs aXBzZQAuAAAAUmVzcG9uc2libGUgUGVlcihSUCkgUmVwbGljYXRpb24gaW4gREhUIGxldmVsACQA AABTdGVwMTogQ2hvb3NlIGxvY2F0aW9uIHRvIHJlcGxpY2F0ZQAgAAAAU3RlcDI6IHdoZW4gcmVw bGljYSBub2RlcyBmYWlsIAAjAAAAU3RlcDM6IHdoZW4gcmVzcG9uc2libGUgcGVlciBmYWlscwAm AAAAU3RlcDQ6IHdoZW4gdGhlIFJQIGNoYW5nZXMgZ3JhY2VmdWxseQA1AAAAU3RlcDU6IGhhbmRs ZSByZXF1ZXN0cyB3aGVuIHJlc3BvbnNpYmxlIHBlZXIgaXMgYnVzeQAMEAAABgAAAB4AAAALAAAA Rm9udHMgVXNlZAADAAAABQAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0A AABTbGlkZSBUaXRsZXMAAwAAAAYAAAAAAAA0AAAAAwAAAAAAAAAgAAAAAQAAAAAA9g8eAAAAFAAA AF/AkeNf/gAABgD0AwMA2jBzNjQwODEIAAAAcwA2ADQAMAA4ADEAAAAtAQEAMgAAACQDFwAkAAAA AAAAgCwAAAAAAAAAAgAAALAEAAATAAAABAgAABQAOAATADwAEgBBABAARQAOAEkACwBNAAgAUAAE AFMAAABVAAAAVQAAAFUAAAAaAAAAGgAAABoAAAAaAAQAAAAtAQIABAAAAAYBAQAEAAAALQEDAAQA AAAnAf//BAAAAPABAAADAAAAHgAHAAAA/AIAAABmZgAAAAQAAAAtAQAABAAAAAYBAQAEAAAALQEB ADIAAAAkAxcAAAAMAAMADgAGABEACAAVAAoAGAAMABwADQAgAA4AJAAOACgADgAsAA0AMAAMADQA CgA4AAgAPAAGAD8AAwBCAAAARQAAAEUAAABFAAAADAAAAAwAAAAMAAAADAAEAAAALQECAAQAAAAG AQEABAAAAC0BAwAEAAAAJwH//xwAAAD7Avj/AAAAAA== --Boundary_(ID_serBVgaczumi4Uh5ySTw6g) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_serBVgaczumi4Uh5ySTw6g)-- From p2psip-bounces@ietf.org Tue Dec 04 11:52:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzazI-0005uI-WA; Tue, 04 Dec 2007 11:51:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzazH-0005tw-De for p2psip@ietf.org; Tue, 04 Dec 2007 11:51:11 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzazF-0005WE-7O for p2psip@ietf.org; Tue, 04 Dec 2007 11:51:11 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzazA-0007Pm-3I; Tue, 04 Dec 2007 17:51:08 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Izaz6-0007nx-Ia; Tue, 04 Dec 2007 17:51:03 +0100 Received: from wooky.tm.uka.de (dhcp-11fb.ietf70.org [130.129.17.251]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id AA1A82FC077; Tue, 4 Dec 2007 17:50:59 +0100 (CET) Message-ID: <4755856D.1090803@tm.uka.de> Date: Tue, 04 Dec 2007 08:50:53 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: jiangxingfeng 36340 Subject: Re: =?ISO-8859-1?Q?=3F=3F=3ARe=3A_=5BP2PSIP=5D_replication_?= =?ISO-8859-1?Q?for_p2psip?= References: <20d2bdfb0712031043q611bfb4djeaa06caed1123b66@mail.gmail.com> <4754547B.5070905@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.8 (/) X-Spam-Report: 1.5 SUBJECT_ENCODED_TWICE Subject: MIME encoded twice 0.0 SUBJECT_EXCESS_QP Subject: quoted-printable encoded unnecessarily -0.8 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.2 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org jiangxingfeng 36340 wrote: >> - "Who Replicates?". There is a second alternative for replication by >> the responsible peer(s). I suppose the approach mentioned in your >> slidesis that the responsible peers pushes the records to all >> replicatingpeers. The second alternative (as it is done in P2PNS) >> is that all >> replicating peers pull the records from all other peers. In this sense >> there is not a single responsible peer, but all neighbors are equally >> responsible. I think having a single responsible peer is a big >> securityproblem. >> > > the pull mode may work. But if the has been changed or deleted, how does the replicating peer learn it has changed? In case the owner modifies a record it pushes it to all currently responsible nodes. This modification is signed with the owner's private key (in P2PNS only the owner is allowed to change a record). Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 12:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbcL-00053L-2Q; Tue, 04 Dec 2007 12:31:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbcK-00052E-Gg for p2psip@ietf.org; Tue, 04 Dec 2007 12:31:32 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzbcJ-0005OU-VP for p2psip@ietf.org; Tue, 04 Dec 2007 12:31:32 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FD7922671; Tue, 4 Dec 2007 18:29:35 +0100 (CET) X-AuditID: c1b4fb3e-b0ea3bb00000459d-f9-47558e7fc00b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 547D722658; Tue, 4 Dec 2007 18:29:35 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 18:29:35 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 18:29:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2612C245F; Tue, 4 Dec 2007 19:29:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E4EAD4DBD7; Tue, 4 Dec 2007 19:29:31 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EFA674DB34; Tue, 4 Dec 2007 19:29:30 +0200 (EET) Message-ID: <47558EEA.4030808@ericsson.com> Date: Tue, 04 Dec 2007 09:31:22 -0800 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com><20071127220309.C632733C28@delta.rtfm.com><4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com><20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> <474EA5DB.4010201@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE363@namail5.corp.adobe.com> <47547762.9050007@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 04 Dec 2007 17:29:34.0501 (UTC) FILETIME=[3CA00550:01C8369B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Dean, Dean Willis wrote: >>> ers and other network elements have to >>> understand HIP? >> >> No they don't. There is no such functions in HIP which would require >> HIP-aware routers (or other middleboxes). > > They do need to be at least HIP tolerant. I think my firewall drops > protocol 253 into the bit-bucket. HIP's extension for NAT traversal makes it possible to use UDP encapsulation for HIP control packets. So, intermediary network elements does not need to be HIP-aware. -- Jani _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 13:08:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcBF-0004gQ-1u; Tue, 04 Dec 2007 13:07:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcBD-0004gD-Bz for p2psip@ietf.org; Tue, 04 Dec 2007 13:07:35 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcBC-0000WZ-IS for p2psip@ietf.org; Tue, 04 Dec 2007 13:07:35 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzcB7-0003Uk-6h; Tue, 04 Dec 2007 19:07:33 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IzcB4-0000gI-67; Tue, 04 Dec 2007 19:07:29 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2FBF62FC076; Tue, 4 Dec 2007 19:07:25 +0100 (CET) Message-ID: <4755975C.3070400@tm.uka.de> Date: Tue, 04 Dec 2007 10:07:24 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Song Yongchao Subject: Re: [P2PSIP] replication for p2psip References: <011f01c83659$10381800$3e05a40a@china.huawei.com> In-Reply-To: <011f01c83659$10381800$3e05a40a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.1 (/) X-Spam-Report: 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 3.0 (+++) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, is there a draft which describes your "Responsible Peer Replication"? As far as I've understood your slides, there are several issues: - What if the responsible peer is malicious? In this case a single malicious node is sufficient to tamper with a stored date record. - In your slides it looks like replica nodes are determined by using multiple hash functions. In this case it is very inefficient for the RP to constantly verify all replica nodes, because there is no direct relationship to these nodes (these nodes a not in your routing tables and are not covered by normal routing table maintenance). - If the RP fails, which of the replica peers is authorized to transfer the record to the new RP? (some of the replica peers could also be malicious). - The load balancing seems to be broken. Why do you always contact the RP first and let than the RP relay the request to one of the replicas? I would be much better to directly contact the replicas yourself. Regards, Ingmar Song Yongchao wrote: > Hi, all > > The attachment is the draft slides for our suggested replication mechanism > in DHT level by the responsible peer. It has the following benefits: > > 1) It can be adapted to all DHT algorithms, > > 2) It can achieve load balance by distributing the requests to replica > nodes, > > 3) The maintenance of replicas is simple, > > 4) It can achieve the availability and persistence of resource objects. > > > Best Regards! > Song Yongchao > > > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] >> Sent: Tuesday, December 04, 2007 2:44 AM >> To: P2PSIP Mailing List >> Subject: [P2PSIP] replication for p2psip >> >> I'm attaching a first draft of slides for the replication discussion >> on Wednesday. (I'm also including the raw text below, which is a >> little bit hard to read.) I have tried to summarize the important >> concepts and issues, and at the end I propose a high-level view of a >> solution, as I perceive the conclusion of the earlier email threads. >> >> I would appreciate specific comments on the slides, missing important >> issues, or just general conversation on these issues. >> >> Bruce >> >> >> >> Replication for P2PSIP >> Bruce Lowekamp >> 12/5/2007 >> 2 >> Replication vs Erasure Codes >> This talk discusses "replication." For >> P2PSIP, where the primary resource is >> a AoR->URI or similar mapping, this is >> the right approach. For storage of >> larger objects, mechanisms such as >> erasure codes are more appropriate. >> Most of the same issues of placement >> and responsibility are still applicable >> with only slight modifications. >> 3 >> The Questions >> What should replication achieve? >> What peer is responsible for replication? >> What layer is responsible? >> How many replicas? >> Where to put the replicas? >> 4 >> Goals of Replication >> Persistence >> ? Data retained after crash of responsible peer >> ? "Permanence" after storing peer leaves >> Security >> ? DoS by responsible peer >> ? Routing attacks along path to responsible peer >> Load Balancing >> ? Queries for a popular resource distributed >> between replicas >> 5 >> Popular Replication Schemes >> Neighbors >> ? Persistence with loss of responsible peer >> ? DHT-dependent definition >> ? Vulnerable to routing attacks >> ? Depends on responsible peer >> Random replicas >> ? Fixed offsets or text addition before hashing >> ? Paths to different replicas are independent >> ? Harder to replace on loss of responsible peer >> Query-path >> ? Replicas added along path to responsible peer >> ? Good for load balancing >> 6 >> Who Replicates? >> Storing (owner) peer >> ? Cares the most about the outcome >> ? Should bear work responsibility >> ? Can't refresh after leaving >> Responsible peer >> ? "Responsible" >> ? Easiest support for "permanent" resources >> ? Low overhead for neighbors >> ? Higher overhead for random replicas >> 7 >> What Layer Replicates? >> DHT >> ? Appropriate replication scheme related to DHT >> algorithm >> Application >> ? Knows requirements >> ?Persistence >> ?Reliability >> ?Popularity >> ? Knows when owner is present >> ? Only layer that can generate new signatures (if >> needed) >> 8 >> Possible Solutions? >> No single approach solves all problems. >> Proposal: We need both >> ? DHT-level replication always appropriate, can't be >> done by application-layer. >> ? Only application-layer knows enough about >> requirements to justify/define further replication. >> ? Responsible peer needs to make application-layer >> decisions about its resources. Not just DHT-level. >> ? Interaction between these layers may be useful to >> detect malicious peers. >> >> ------------------------------------------------------------------------ >> >> This body part will be downloaded on demand. -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 13:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcDc-0007Sp-17; Tue, 04 Dec 2007 13:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcDb-0007QL-4I for p2psip@ietf.org; Tue, 04 Dec 2007 13:10:03 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcDa-0005Bk-If for p2psip@ietf.org; Tue, 04 Dec 2007 13:10:03 -0500 Received: from dhcp-13bf.ietf70.org ([130.129.19.191]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1IzcDZ-000Pcn-Pw; Tue, 04 Dec 2007 18:10:02 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 130.129.19.191 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19YBmssB5ZqlFEzOAewBmgJH65fKBAohyc= Message-ID: <475597F7.5010903@sipstation.com> Date: Tue, 04 Dec 2007 12:09:59 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Initial slides for Wednesday References: <20071203050744.C50D033C47@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE384@namail5.corp.adobe.com> <20d2bdfb0712031010p2eb1ee60t210cb9f2e4d0f4e8@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE386@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE386@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: p2psip@ietf.org, Philip Zimmermann X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Henry, In answer to your question about the status of ZRTP, it is working its way towards completion and publication as an informational RFC. Thanks, Alan. Henry Sinnreich wrote: > Thanks Bruce for the agreement! > > I should have added that a possible lightweight solution at the > application layer is to just store ZRTP "somethings" in my address book. > There would be no ZRTP entries for "uninteresting contacts" :-) > > Reminder: What is the status of the ZRTP I-D? > We may need it for P2PSIP sooner than later. > > Henry > > -----Original Message----- > From: lowekamp@gmail.com [mailto:lowekamp@gmail.com] On Behalf Of Bruce > Lowekamp > Sent: Monday, December 03, 2007 12:11 PM > To: Henry Sinnreich > Cc: Eric Rescorla; p2psip@ietf.org > Subject: Re: [P2PSIP] Initial slides for Wednesday > > Henry, > > I think you're right that there are other aspects to the security > problem. Observing routing behavior is a very useful step since it > helps when an attacker gains control of a peerid. Relying on > user-level authentication can also be useful in certain scenarios. > > As that OSDI paper states, these techniques are complementary to, not > alternatives to, established techniques for authentication such as > certificates. But we do need to discuss both. > > Bruce > > > On 12/3/07, Henry Sinnreich wrote: > >> Certificates are a critical tool, but are they the only tool as >> > implied > >> in slides? >> >> What a about other schemas that may be more effective as the case may >> be: >> >> At the p2p overlay, for routing, checking the consistency of the >> > routing > >> table entries can tell us if there are misbehaving nodes: >> >> http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf >> >> Between the app and p2p layers, secure interfaces are also defined in >> the above. >> >> At the application layer, I don't need certs for the entries in the >> buddy list. Who is not my buddy (organizations) can be found and >> contacted on the web. >> >> I suggest adding some words to the effect when certificates are a good >> option and what alternatives there are, for what scenarios. >> >> Note: As H. Schulzrinne has mentioned, certifying a party that decides >> to act with malice does not help with security. Observing malicious >> behavior will do the trick far better. >> >> Henry >> >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> Sent: Sunday, December 02, 2007 11:08 PM >> To: p2psip@ietf.org >> Subject: [P2PSIP] Initial slides for Wednesday >> >> Here are my prototype slides for Tuesday's discussion. >> >> -Ekr >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> >> > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 13:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcDz-00084U-FD; Tue, 04 Dec 2007 13:10:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcDx-0007wA-Ri for p2psip@ietf.org; Tue, 04 Dec 2007 13:10:25 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzcDx-0000mp-Hj for p2psip@ietf.org; Tue, 04 Dec 2007 13:10:25 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSJ005LSEHC9K@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 10:10:25 -0800 (PST) Received: from s73602 (dhcp-17a0.ietf70.org [130.129.23.160]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSJ0054KEHAZG@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 04 Dec 2007 10:10:24 -0800 (PST) Date: Tue, 04 Dec 2007 10:10:13 -0800 From: Spencer Dawkins Subject: Re: [P2PSIP] Agenda for the upcoming meeting inVancouver (existentialist topics) To: "Jani Hautakorpi (JO/LMF)" , Dean Willis Message-id: <092101c836a0$eabe33a0$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <20071127220309.C632733C28@delta.rtfm.com> <4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com> <20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> <474EA5DB.4010201@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE363@namail5.corp.adobe.com> <47547762.9050007@ericsson.com> <47558EEA.4030808@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I've said this privately but not onlist - sorry. I would really love to agree on a protocol stack for these proposals. If there's a known answer, that's fine, but I haven't found it yet. Spencer > Hi Dean, > > Dean Willis wrote: >>>> ers and other network elements have to >>>> understand HIP? >>> >>> No they don't. There is no such functions in HIP which would require >>> HIP-aware routers (or other middleboxes). >> >> They do need to be at least HIP tolerant. I think my firewall drops >> protocol 253 into the bit-bucket. > > HIP's extension for NAT traversal makes it possible to use UDP > encapsulation for HIP control packets. So, intermediary network elements > does not need to be HIP-aware. > > > -- > Jani > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 21:14:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjlX-00039v-Bu; Tue, 04 Dec 2007 21:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjlV-00031x-45 for p2psip@ietf.org; Tue, 04 Dec 2007 21:13:33 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzjlT-0008Ai-6g for p2psip@ietf.org; Tue, 04 Dec 2007 21:13:33 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK00M820TCVC@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 10:12:48 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK0082D0TBG3@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 10:12:48 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSK003OT0TAYD@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 10:12:47 +0800 (CST) Date: Wed, 05 Dec 2007 10:12:46 +0800 From: Song Yongchao Subject: RE: [P2PSIP] replication for p2psip In-reply-to: <4754C92C.3000900@tm.uka.de> To: 'Ingmar Baumgart' Message-id: <00ba01c836e4$53f72b90$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acg2JbZJePBBrEo9RvadqTCFa355QwAvLywg X-Spam-Score: 1.2 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] > Sent: Tuesday, December 04, 2007 11:28 AM > To: Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] replication for p2psip > > Every time a peer joins it retrieves all data records close to his > nodeID by querying all his neighbors. To ensure consistency this can be > repeated periodically (e.g. every hour). I don't think it works. A peer usually has tens of entries in his neighbor table. Why do you pull resource objects from all his neighbors? Why do we need so many replicas? That is a large waste of bandwidth and storage. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 21:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkPy-0002YO-Sf; Tue, 04 Dec 2007 21:55:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkPx-0002Ng-Eg for p2psip@ietf.org; Tue, 04 Dec 2007 21:55:21 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzkPv-0005QI-V2 for p2psip@ietf.org; Tue, 04 Dec 2007 21:55:21 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK00KBR2R1FY@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 10:54:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK006YO2R0NW@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 10:54:37 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSK004HY2QZ1E@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 10:54:36 +0800 (CST) Date: Wed, 05 Dec 2007 10:54:35 +0800 From: Song Yongchao Subject: RE: [P2PSIP] replication for p2psip In-reply-to: <4755975C.3070400@tm.uka.de> To: 'Ingmar Baumgart' Message-id: <00bb01c836ea$2ba57510$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acg2oIq3AqH9vmc6QMemqv524JggRwARMF4g X-Spam-Score: 3.0 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] > Sent: Wednesday, December 05, 2007 2:07 AM > To: Song Yongchao > Cc: 'Bruce Lowekamp'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] replication for p2psip >=20 > Hi, >=20 > is there a draft which describes your "Responsible Peer Replication"? We will prepare a draft when needed. > As far as I've understood your slides, there are several issues: >=20 > - What if the responsible peer is malicious? In this case a single > malicious node is sufficient to tamper with a stored date record. Resource object has the signature with the owner's private key. No peer except the owner can modify the resource object. > - In your slides it looks like replica nodes are determined by using > multiple hash functions. In this case it is very inefficient for the = RP > to constantly verify all replica nodes, because there is no direct > relationship to these nodes (these nodes a not in your routing tables > and are not covered by normal routing table maintenance). >=20 How to choose replica nodes is an open issue. Powerful nodes with enough spare space in the neighbor/routing table are preferred. Other peers = that can provide large storage service can also be taken into account. The number of replicas needed is determined by the overly churn rate. It = is an open issue that should be discussed in the mail list. > - If the RP fails, which of the replica peers is authorized to = transfer > the record to the new RP? (some of the replica peers could also be > malicious). Any replica peer that detects the failure of the RP must lookup with the = key of the resource object in the overlay. Then any replica peer can find = the new responsible peer for the record. This can be adapted to all DHT algorithms. The replica peer that first detects the failure must = transfer the record to the new RP. The security of the record is protected by signature with the owner's private key. BR Song Yongchao > Regards, > Ingmar >=20 > Song Yongchao wrote: > > Hi, all > > > > The attachment is the draft slides for our suggested replication mechanism > > in DHT level by the responsible peer. It has the following benefits: > > > > 1) It can be adapted to all DHT algorithms, > > > > 2) It can achieve load balance by distributing the requests to = replica > > nodes, > > > > 3) The maintenance of replicas is simple, > > > > 4) It can achieve the availability and persistence of resource = objects. > > > > > > Best Regards! > > Song Yongchao > > > > > > > >> -----Original Message----- > >> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > >> Sent: Tuesday, December 04, 2007 2:44 AM > >> To: P2PSIP Mailing List > >> Subject: [P2PSIP] replication for p2psip > >> > >> I'm attaching a first draft of slides for the replication = discussion > >> on Wednesday. (I'm also including the raw text below, which is a > >> little bit hard to read.) I have tried to summarize the important > >> concepts and issues, and at the end I propose a high-level view of = a > >> solution, as I perceive the conclusion of the earlier email = threads. > >> > >> I would appreciate specific comments on the slides, missing = important > >> issues, or just general conversation on these issues. > >> > >> Bruce > >> > >> > >> > >> Replication for P2PSIP > >> Bruce Lowekamp > >> 12/5/2007 > >> 2 > >> Replication vs Erasure Codes > >> This talk discusses "replication." For > >> P2PSIP, where the primary resource is > >> a AoR->URI or similar mapping, this is > >> the right approach. For storage of > >> larger objects, mechanisms such as > >> erasure codes are more appropriate. > >> Most of the same issues of placement > >> and responsibility are still applicable > >> with only slight modifications. > >> 3 > >> The Questions > >> What should replication achieve? > >> What peer is responsible for replication? > >> What layer is responsible? > >> How many replicas? > >> Where to put the replicas? > >> 4 > >> Goals of Replication > >> Persistence > >> ? Data retained after crash of responsible peer > >> ? "Permanence" after storing peer leaves > >> Security > >> ? DoS by responsible peer > >> ? Routing attacks along path to responsible peer > >> Load Balancing > >> ? Queries for a popular resource distributed > >> between replicas > >> 5 > >> Popular Replication Schemes > >> Neighbors > >> ? Persistence with loss of responsible peer > >> ? DHT-dependent definition > >> ? Vulnerable to routing attacks > >> ? Depends on responsible peer > >> Random replicas > >> ? Fixed offsets or text addition before hashing > >> ? Paths to different replicas are independent > >> ? Harder to replace on loss of responsible peer > >> Query-path > >> ? Replicas added along path to responsible peer > >> ? Good for load balancing > >> 6 > >> Who Replicates? > >> Storing (owner) peer > >> ? Cares the most about the outcome > >> ? Should bear work responsibility > >> ? Can't refresh after leaving > >> Responsible peer > >> ? "Responsible" > >> ? Easiest support for "permanent" resources > >> ? Low overhead for neighbors > >> ? Higher overhead for random replicas > >> 7 > >> What Layer Replicates? > >> DHT > >> ? Appropriate replication scheme related to DHT > >> algorithm > >> Application > >> ? Knows requirements > >> ?Persistence > >> ?Reliability > >> ?Popularity > >> ? Knows when owner is present > >> ? Only layer that can generate new signatures (if > >> needed) > >> 8 > >> Possible Solutions? > >> No single approach solves all problems. > >> Proposal: We need both > >> ? DHT-level replication always appropriate, can't be > >> done by application-layer. > >> ? Only application-layer knows enough about > >> requirements to justify/define further replication. > >> ? Responsible peer needs to make application-layer > >> decisions about its resources. Not just DHT-level. > >> ? Interaction between these layers may be useful to > >> detect malicious peers. > >> > >> > = ------------------------------------------------------------------------ > >> > >> This body part will be downloaded on demand. >=20 > -- > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 21:59:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkUI-0006Co-MV; Tue, 04 Dec 2007 21:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkUH-0006B2-Ie for p2psip@ietf.org; Tue, 04 Dec 2007 21:59:49 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzkUH-00027m-1g for p2psip@ietf.org; Tue, 04 Dec 2007 21:59:49 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IzkUD-0007WS-R9; Wed, 05 Dec 2007 03:59:48 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IzkUA-0007Uw-TH; Wed, 05 Dec 2007 03:59:45 +0100 Received: from wooky.tm.uka.de (dhcp-11fb.ietf70.org [130.129.17.251]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 24B8C2FC077; Wed, 5 Dec 2007 03:59:41 +0100 (CET) Message-ID: <4756141E.5000902@tm.uka.de> Date: Tue, 04 Dec 2007 18:59:42 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Song Yongchao Subject: Re: [P2PSIP] replication for p2psip References: <00ba01c836e4$53f72b90$3e05a40a@china.huawei.com> In-Reply-To: <00ba01c836e4$53f72b90$3e05a40a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.2 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Song Yongchao wrote: >> -----Original Message----- >> From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] >> Sent: Tuesday, December 04, 2007 11:28 AM >> To: Bruce Lowekamp >> Cc: P2PSIP Mailing List >> Subject: Re: [P2PSIP] replication for p2psip >> >> Every time a peer joins it retrieves all data records close to his >> nodeID by querying all his neighbors. To ensure consistency this can be >> repeated periodically (e.g. every hour). > > I don't think it works. A peer usually has tens of entries in his neighbor > table. Why do you pull resource objects from all his neighbors? Why do we > need so many replicas? That is a large waste of bandwidth and storage. Sorry, querying "all neighbors" was a bit vague. Actually we query only the k closest neighbors (k could also be as small as 1). Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 04 22:40:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izl5U-0003BN-6i; Tue, 04 Dec 2007 22:38:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izl5S-00034r-FZ for p2psip@ietf.org; Tue, 04 Dec 2007 22:38:14 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izl5R-0007SK-GY for p2psip@ietf.org; Tue, 04 Dec 2007 22:38:14 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Izl5N-0004RV-61; Wed, 05 Dec 2007 04:38:12 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Izl5K-0007vz-63; Wed, 05 Dec 2007 04:38:09 +0100 Received: from wooky.tm.uka.de (dhcp-11fb.ietf70.org [130.129.17.251]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 14B022FC077; Wed, 5 Dec 2007 04:38:04 +0100 (CET) Message-ID: <47561D1D.8090500@tm.uka.de> Date: Tue, 04 Dec 2007 19:38:05 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Song Yongchao Subject: Re: [P2PSIP] replication for p2psip References: <00bb01c836ea$2ba57510$3e05a40a@china.huawei.com> In-Reply-To: <00bb01c836ea$2ba57510$3e05a40a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 3.0 (+++) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Okay, so this depends on the requirements the application has for DHT layer security. Signing a resource object does not prevent a malicious node from not storing the object or adding an additional object with the same ID. Regards, Ingmar Song Yongchao wrote: >> -----Original Message----- >> From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] >> Sent: Wednesday, December 05, 2007 2:07 AM >> To: Song Yongchao >> Cc: 'Bruce Lowekamp'; 'P2PSIP Mailing List' >> Subject: Re: [P2PSIP] replication for p2psip >> >> Hi, >> >> is there a draft which describes your "Responsible Peer Replication"? > > We will prepare a draft when needed. > >> As far as I've understood your slides, there are several issues: >> >> - What if the responsible peer is malicious? In this case a single >> malicious node is sufficient to tamper with a stored date record. > > Resource object has the signature with the owner's private key. No peer > except the owner can modify the resource object. > >> - In your slides it looks like replica nodes are determined by using >> multiple hash functions. In this case it is very inefficient for the RP >> to constantly verify all replica nodes, because there is no direct >> relationship to these nodes (these nodes a not in your routing tables >> and are not covered by normal routing table maintenance). >> > How to choose replica nodes is an open issue. Powerful nodes with enough > spare space in the neighbor/routing table are preferred. Other peers that > can provide large storage service can also be taken into account. > > The number of replicas needed is determined by the overly churn rate. It is > an open issue that should be discussed in the mail list. > >> - If the RP fails, which of the replica peers is authorized to transfer >> the record to the new RP? (some of the replica peers could also be >> malicious). > > Any replica peer that detects the failure of the RP must lookup with the key > of the resource object in the overlay. Then any replica peer can find the > new responsible peer for the record. This can be adapted to all DHT > algorithms. The replica peer that first detects the failure must transfer > the record to the new RP. The security of the record is protected by > signature with the owner's private key. > > BR > Song Yongchao > > >> Regards, >> Ingmar >> >> Song Yongchao wrote: >>> Hi, all >>> >>> The attachment is the draft slides for our suggested replication > mechanism >>> in DHT level by the responsible peer. It has the following benefits: >>> >>> 1) It can be adapted to all DHT algorithms, >>> >>> 2) It can achieve load balance by distributing the requests to replica >>> nodes, >>> >>> 3) The maintenance of replicas is simple, >>> >>> 4) It can achieve the availability and persistence of resource objects. >>> >>> >>> Best Regards! >>> Song Yongchao >>> >>> >>> >>>> -----Original Message----- >>>> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] >>>> Sent: Tuesday, December 04, 2007 2:44 AM >>>> To: P2PSIP Mailing List >>>> Subject: [P2PSIP] replication for p2psip >>>> >>>> I'm attaching a first draft of slides for the replication discussion >>>> on Wednesday. (I'm also including the raw text below, which is a >>>> little bit hard to read.) I have tried to summarize the important >>>> concepts and issues, and at the end I propose a high-level view of a >>>> solution, as I perceive the conclusion of the earlier email threads. >>>> >>>> I would appreciate specific comments on the slides, missing important >>>> issues, or just general conversation on these issues. >>>> >>>> Bruce >>>> >>>> >>>> >>>> Replication for P2PSIP >>>> Bruce Lowekamp >>>> 12/5/2007 >>>> 2 >>>> Replication vs Erasure Codes >>>> This talk discusses "replication." For >>>> P2PSIP, where the primary resource is >>>> a AoR->URI or similar mapping, this is >>>> the right approach. For storage of >>>> larger objects, mechanisms such as >>>> erasure codes are more appropriate. >>>> Most of the same issues of placement >>>> and responsibility are still applicable >>>> with only slight modifications. >>>> 3 >>>> The Questions >>>> What should replication achieve? >>>> What peer is responsible for replication? >>>> What layer is responsible? >>>> How many replicas? >>>> Where to put the replicas? >>>> 4 >>>> Goals of Replication >>>> Persistence >>>> ? Data retained after crash of responsible peer >>>> ? "Permanence" after storing peer leaves >>>> Security >>>> ? DoS by responsible peer >>>> ? Routing attacks along path to responsible peer >>>> Load Balancing >>>> ? Queries for a popular resource distributed >>>> between replicas >>>> 5 >>>> Popular Replication Schemes >>>> Neighbors >>>> ? Persistence with loss of responsible peer >>>> ? DHT-dependent definition >>>> ? Vulnerable to routing attacks >>>> ? Depends on responsible peer >>>> Random replicas >>>> ? Fixed offsets or text addition before hashing >>>> ? Paths to different replicas are independent >>>> ? Harder to replace on loss of responsible peer >>>> Query-path >>>> ? Replicas added along path to responsible peer >>>> ? Good for load balancing >>>> 6 >>>> Who Replicates? >>>> Storing (owner) peer >>>> ? Cares the most about the outcome >>>> ? Should bear work responsibility >>>> ? Can't refresh after leaving >>>> Responsible peer >>>> ? "Responsible" >>>> ? Easiest support for "permanent" resources >>>> ? Low overhead for neighbors >>>> ? Higher overhead for random replicas >>>> 7 >>>> What Layer Replicates? >>>> DHT >>>> ? Appropriate replication scheme related to DHT >>>> algorithm >>>> Application >>>> ? Knows requirements >>>> ?Persistence >>>> ?Reliability >>>> ?Popularity >>>> ? Knows when owner is present >>>> ? Only layer that can generate new signatures (if >>>> needed) >>>> 8 >>>> Possible Solutions? >>>> No single approach solves all problems. >>>> Proposal: We need both >>>> ? DHT-level replication always appropriate, can't be >>>> done by application-layer. >>>> ? Only application-layer knows enough about >>>> requirements to justify/define further replication. >>>> ? Responsible peer needs to make application-layer >>>> decisions about its resources. Not just DHT-level. >>>> ? Interaction between these layers may be useful to >>>> detect malicious peers. >>>> >>>> >> ------------------------------------------------------------------------ >>>> This body part will be downloaded on demand. >> -- >> Dipl.-Inform. Ingmar Baumgart >> Institut für Telematik, Universität Karlsruhe (TH) >> Zirkel 2, 76128 Karlsruhe, Germany >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 04:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izqf1-0002Y6-Jd; Wed, 05 Dec 2007 04:35:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izqez-0002UE-TI for p2psip@ietf.org; Wed, 05 Dec 2007 04:35:17 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izqez-0001tr-Ku for p2psip@ietf.org; Wed, 05 Dec 2007 04:35:17 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK00J92LASD2@usaga01-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 01:35:17 -0800 (PST) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK0083MLAQXB@usaga01-in.huawei.com> for p2psip@ietf.org; Wed, 05 Dec 2007 01:35:16 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.66.76]) by szxmc03-in.huawei.com (mshttpd); Wed, 05 Dec 2007 17:35:07 +0800 Date: Wed, 05 Dec 2007 17:35:07 +0800 From: jiangxingfeng 36340 Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver To: Philip Matthews , P2PSIP Mailing List Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi,Philip: I think 4) should be discussed. For ICE, if the candiate pairs could work, the two candiate address of the both peers must exist in the same address realm. If they are not in the same address realm, it won't work. So if the two end nodes which want to communicate with each choose the STUN or TURN servers which are in different address realm, it will make the ICE procedure fail. 4) How does a peer locate STUN and TURN servers? _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 11:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izwr8-0003qs-GK; Wed, 05 Dec 2007 11:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izwr6-0003pN-Fr for p2psip@ietf.org; Wed, 05 Dec 2007 11:12:12 -0500 Received: from qb-out-0506.google.com ([72.14.204.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izwr5-00084v-5i for p2psip@ietf.org; Wed, 05 Dec 2007 11:12:12 -0500 Received: by qb-out-0506.google.com with SMTP id o21so3798604qba for ; Wed, 05 Dec 2007 08:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=taOF7BverON+nHFeAL6T/+Upg5droP31iZsyJp/4bPw=; b=sHIV6bId+KoeC+EK5Z2pAWxwJDd8tHkKsWotS6eIgEnJ5ZLOepCqfj0bcxROZKERHDzJTl+iszF4HQeoLCXm4F/Y42nyic89smHP0lK5+HUNBqG9/+zJTZBKWInqIqEC/PwRrHH5d45O6cAyjJGEINQnaqJdLgYPu1FMcuaokO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=RwpJELoWFB3QLUyBENUGyHDkSuvUYSHopwjpEH1y3o48oEIsE9jxLxq6XdAoTptUtX7m3jrB93+CZlX3OsVQ+RiNTibpJP1Z8NyJBbJg9bvBaR6DkSCe53FXN3YQN0lQ3G++8IF2kYKaT0JW1o+PalfEb/LG8VrakoWjlCN2KKc= Received: by 10.65.250.11 with SMTP id c11mr1459673qbs.1196871130315; Wed, 05 Dec 2007 08:12:10 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 5 Dec 2007 08:12:10 -0800 (PST) Message-ID: <4d4304a00712050812v1f0a4e0dg6846aa870e008d9f@mail.gmail.com> Date: Wed, 5 Dec 2007 08:12:10 -0800 From: "David A. Bryan" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 308ea9adafcfecf4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [P2PSIP] Slides available X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The slides as they will be presented have been uploaded to https://datatracker.ietf.org/meeting/70/materials.html (we are about half way down) See everyone at the meeting. David -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 14:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzkQ-0007w0-Is; Wed, 05 Dec 2007 14:17:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzkP-0007vo-7F for p2psip@ietf.org; Wed, 05 Dec 2007 14:17:29 -0500 Received: from rn-out-0910.google.com ([64.233.170.190] helo=rn-out-0102.google.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzzkO-0004nP-NP for p2psip@ietf.org; Wed, 05 Dec 2007 14:17:29 -0500 Received: by rn-out-0102.google.com with SMTP id i50so2907718rne for ; Wed, 05 Dec 2007 11:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=ICPVZtM/U790wyNdIkHSnJTva7cf24F6tF7bHkA0hVY=; b=RBTMi5fz3g6FC0XSOmJBworVTXeNDgg7A5ooW95BJhBrqVQ4AFM3FCcGExB7bvbrrOR/TzrQvDe1ApPgwBX8p1igOnU3ynfqzb9/39ZF/NXVyqeilCCGvQ7dUEi7Dv7+7G0La/oishEZOaZInI62qEJlh99ueB0kyZ2BmP/3GUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=MyCxYccEnaXj2h2bACzfeePT0U0IISZVyT3Ihy4koAv44kyhxisZA/nD3/5MxPOEQJbfDCdJuP0O42Dad5pnMDYO5b+gPOQKSnke4L1ipfzHlcbT4E2bVwKKjefBvqpmQ350Ln7MM2VDNdgI72HrHTLL9uiPEu2Yn+dqtdfh8Oo= Received: by 10.142.171.6 with SMTP id t6mr1213787wfe.1196882245447; Wed, 05 Dec 2007 11:17:25 -0800 (PST) Received: by 10.142.132.18 with HTTP; Wed, 5 Dec 2007 11:17:25 -0800 (PST) Message-ID: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> Date: Wed, 5 Dec 2007 11:17:25 -0800 From: "Bruce Lowekamp" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 98a4bcf612401248 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [P2PSIP] client protocol architectural issues X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org There has been tons of discussions on the issue of "do we need a client protocol?" or "why do we need a client protocol?" We have the topic again on the agenda this afternoon. I want to make two assertions: - we need a client protocol. There's just a lot of disagreement on what it looks like. - most of the peer protocol proposals have a way of integrating clients at the p2p layer. there is some question as to what capabilities are needed at this layer. The major controversy seems to be over architecture. Three options include: 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP devices. Primary communication between a client and peer will be using the peer as its default outbound proxy, with any SIP extensions handled at the SIP layer, as in draft-li-p2psip-client-protocol. 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are SIP devices and may need to interact with a peer using P2P protocol GET/STORE operations. 3) P2PSIP peers and clients are not necessarily either SIP devices. A client may try to participate in the overlay by contributing storage to help peers or other functions generally associated with overlay peers without actually participating in all of the peer functionality. My personal belief is that the primary P2PSIP architecture should be (1). I think there are justifications for architecture (2), and I think that most/all of the protocol proposals support this. I am concerned about (3). I know that many real P2P deployments support this type of behavior. In one sentence, my understanding is that that primary motivation for these deployments is a way of making use of devices behind NATs. I think we (p2psip) have been looking at different (and more complicated) NAT traversal solutions (ICE/tunneling) because we believe many of our application scenarios don't have the same global deployment features, and we are aiming at topologies where most of our peers are behind NATs. (unlike topologies where most devices are in college dorms) Supporting (3) significantly complicates the protocol (in other directions than it is already complicated by other requirements such as NAT traversal). One of my reasons for being unsure whether we need it is that for P2PSIP, there are already SIP-level ways of providing services to the overlay. In a lot of senses, merely registering an AoR to peerid/ip mapping is providing services, because one of the fundamental roles of a SIP device is to provide SIP services. For the P2PSIP case, other than resource storage, what are these services that don't fit within the SIP model? For applications other than SIP, what are these services? Wouldn't any other application have its own application-level way of offering services? If there is consensus that it is important for the peer protocol to support peer/client interaction that allows the clients to provide storage (and maybe other peer-level functionality), I'm OK with that as long as it is optional and ideally not in the core draft, something like draft-zheng-p2psip-client-protocol. If the need for a "client protocol" for devices that provides "services" requires a different architecture, I'm very curious what they are and specific reasons why they exist and are not either providing SIP services or merely needing to do GET/STORE with the overlay to register their presence. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 14:35:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J001K-0006ad-L4; Wed, 05 Dec 2007 14:34:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J001I-0006Zy-Nx for p2psip@ietf.org; Wed, 05 Dec 2007 14:34:56 -0500 Received: from mxoutps1.us.army.mil ([143.69.250.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J001H-0006Sl-BI for p2psip@ietf.org; Wed, 05 Dec 2007 14:34:56 -0500 DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; b=IZxtiQIzuKIVnqAVkTdk7lMV+y0jNuRXfyssJXSacEbQFIrYgEY/umO+mV8Thl4bvRrUPTbIwbhgRiM2jGsi1g==; Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 05 Dec 2007 19:34:53 +0000 From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 86761551:10.224.36.65:05 Dec 2007 19:34:53 +0000:$Webmail:None X-IronPort-AV: i="4.23,255,1194220800"; d="scan'208"; a="86761551:sNHT91111311" Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Wed, 05 Dec 2007 14:34:53 -0500 To: Bruce Lowekamp Message-ID: Date: Wed, 05 Dec 2007 14:34:53 -0500 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en Subject: Re: [P2PSIP] client protocol architectural issues X-Accept-Language: en Priority: normal In-Reply-To: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce: I like your suggestion for P2PSIP Client protocol. Let me add a little as follows: a. Let your option (1) be the choice. b. Let additional methods like GET/STORE. c. Let it could have storage and other properties. Items (b) and (c) may be added as a set of separate properties in the name of protocol/feature/capabilities and we may not call them SIP. Because any extensions of SIP for items b and c will NOT have the properties of the SIP protocol for which SIP has been charted. Moreover, we not charted to extend SIP. The combination items a, b, and c will make a P2P Client (i.e. SIP UA + P2PSIP Client UA) and the combined protocol may be termed as P2PSIP Client protocol. How about this? Best regards, Radhika ----- Original Message ----- From: Bruce Lowekamp Date: Wednesday, December 5, 2007 14:17 Subject: [P2PSIP] client protocol architectural issues To: P2PSIP Mailing List > There has been tons of discussions on the issue of "do we need a > client protocol?" or "why do we need a client protocol?" We have the > topic again on the agenda this afternoon. > > > I want to make two assertions: > - we need a client protocol. There's just a lot of disagreement on > what it looks like. > - most of the peer protocol proposals have a way of integrating > clients at the p2p layer. there is some question as to what > capabilities are needed at this layer. > > > > The major controversy seems to be over architecture. Three > options include: > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > devices. Primary communication between a client and peer will be > using the peer as its default outbound proxy, with any SIP extensions > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > SIP devices and may need to interact with a peer using P2P protocol > GET/STORE operations. > 3) P2PSIP peers and clients are not necessarily either SIP > devices. A > client may try to participate in the overlay by contributing storage > to help peers or other functions generally associated with overlay > peers without actually participating in all of the peer functionality. > > > > My personal belief is that the primary P2PSIP architecture should > be (1). > > I think there are justifications for architecture (2), and I think > that most/all of the protocol proposals support this. > > I am concerned about (3). I know that many real P2P deployments > support this type of behavior. In one sentence, my understanding is > that that primary motivation for these deployments is a way of making > use of devices behind NATs. I think we (p2psip) have been looking at > different (and more complicated) NAT traversal solutions > (ICE/tunneling) because we believe many of our application scenarios > don't have the same global deployment features, and we are aiming at > topologies where most of our peers are behind NATs. (unlike > topologies where most devices are in college dorms) > > Supporting (3) significantly complicates the protocol (in other > directions than it is already complicated by other requirements such > as NAT traversal). One of my reasons for being unsure whether we need > it is that for P2PSIP, there are already SIP-level ways of providing > services to the overlay. In a lot of senses, merely registering an > AoR to peerid/ip mapping is providing services, because one of the > fundamental roles of a SIP device is to provide SIP services. For the > P2PSIP case, other than resource storage, what are these services that > don't fit within the SIP model? For applications other than SIP, what > are these services? Wouldn't any other application have its own > application-level way of offering services? > > If there is consensus that it is important for the peer protocol to > support peer/client interaction that allows the clients to provide > storage (and maybe other peer-level functionality), I'm OK with that > as long as it is optional and ideally not in the core draft, something > like draft-zheng-p2psip-client-protocol. > > If the need for a "client protocol" for devices that provides > "services" requires a different architecture, I'm very curious what > they are and specific reasons why they exist and are not either > providing SIP services or merely needing to do GET/STORE with the > overlay to register their presence. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 14:47:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J00Dl-0007W5-5x; Wed, 05 Dec 2007 14:47:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J00Dj-0007VT-3x for p2psip@ietf.org; Wed, 05 Dec 2007 14:47:47 -0500 Received: from rv-out-0910.google.com ([209.85.198.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J00Di-0007kr-3R for p2psip@ietf.org; Wed, 05 Dec 2007 14:47:46 -0500 Received: by rv-out-0910.google.com with SMTP id l15so3542356rvb for ; Wed, 05 Dec 2007 11:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pRs7Ft3CYUZUJJD4dyCVxAzzaihU7yCsFla+gfPRt9A=; b=lwfJLyIG8Y8BiXomygTCf44gYauNq7G1mXoigILnKvBpIHqcboehL9koB7BaEV0csyx3LAOBGnCbL6ebW5u/WtCqg/eW49S8DYXNaeJqH5fgf8FByHzt6Zwf1ykAVbFevNtYAFYLjxl7d71cAJSEpXslHgYnFXZ0sGIkizo8OnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SUi7fItjtkizwN2lCwYi1Zs6Nxi0tQ8/ivpuZ3JPUzq2E7H3hZ9xs6ef4hwHs8uUpfWpr9whbd1f/MO3huRaL9aw5Bsac8RUgFn+MOJ/FJKqjb+DWHP37pBO8p7yzGPofgNYXanUhEN1OsKjKvFfAo5lzqc0ekWAcrWxoGnKTHg= Received: by 10.140.163.3 with SMTP id l3mr1442361rve.1196884064195; Wed, 05 Dec 2007 11:47:44 -0800 (PST) Received: by 10.141.40.5 with HTTP; Wed, 5 Dec 2007 11:47:44 -0800 (PST) Message-ID: <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> Date: Wed, 5 Dec 2007 14:47:44 -0500 From: "Eunsoo Shim" To: "Bruce Lowekamp" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I am opt for (3). I don't see a reason to limit the application of the overlay to SIP. Why would you care whether GET/PUT is used for SIP or any other application layer protocol? Why does option (3) make the peer protocol (and the client protocol) more complex? Thanks. Eunsoo On Dec 5, 2007 2:17 PM, Bruce Lowekamp wrote: > There has been tons of discussions on the issue of "do we need a > client protocol?" or "why do we need a client protocol?" We have the > topic again on the agenda this afternoon. > > > I want to make two assertions: > - we need a client protocol. There's just a lot of disagreement on > what it looks like. > - most of the peer protocol proposals have a way of integrating > clients at the p2p layer. there is some question as to what > capabilities are needed at this layer. > > > > The major controversy seems to be over architecture. Three options include: > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > devices. Primary communication between a client and peer will be > using the peer as its default outbound proxy, with any SIP extensions > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > SIP devices and may need to interact with a peer using P2P protocol > GET/STORE operations. > 3) P2PSIP peers and clients are not necessarily either SIP devices. A > client may try to participate in the overlay by contributing storage > to help peers or other functions generally associated with overlay > peers without actually participating in all of the peer functionality. > > > > My personal belief is that the primary P2PSIP architecture should be (1). > > I think there are justifications for architecture (2), and I think > that most/all of the protocol proposals support this. > > I am concerned about (3). I know that many real P2P deployments > support this type of behavior. In one sentence, my understanding is > that that primary motivation for these deployments is a way of making > use of devices behind NATs. I think we (p2psip) have been looking at > different (and more complicated) NAT traversal solutions > (ICE/tunneling) because we believe many of our application scenarios > don't have the same global deployment features, and we are aiming at > topologies where most of our peers are behind NATs. (unlike > topologies where most devices are in college dorms) > > Supporting (3) significantly complicates the protocol (in other > directions than it is already complicated by other requirements such > as NAT traversal). One of my reasons for being unsure whether we need > it is that for P2PSIP, there are already SIP-level ways of providing > services to the overlay. In a lot of senses, merely registering an > AoR to peerid/ip mapping is providing services, because one of the > fundamental roles of a SIP device is to provide SIP services. For the > P2PSIP case, other than resource storage, what are these services that > don't fit within the SIP model? For applications other than SIP, what > are these services? Wouldn't any other application have its own > application-level way of offering services? > > If there is consensus that it is important for the peer protocol to > support peer/client interaction that allows the clients to provide > storage (and maybe other peer-level functionality), I'm OK with that > as long as it is optional and ideally not in the core draft, something > like draft-zheng-p2psip-client-protocol. > > If the need for a "client protocol" for devices that provides > "services" requires a different architecture, I'm very curious what > they are and specific reasons why they exist and are not either > providing SIP services or merely needing to do GET/STORE with the > overlay to register their presence. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 15:44:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0168-00051n-EM; Wed, 05 Dec 2007 15:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0167-00051X-CM for p2psip@ietf.org; Wed, 05 Dec 2007 15:43:59 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0165-0000uX-CU for p2psip@ietf.org; Wed, 05 Dec 2007 15:43:59 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0161-0001Cw-0A; Wed, 05 Dec 2007 21:43:56 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1J015x-0001N9-RV; Wed, 05 Dec 2007 21:43:52 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id EA6072FC00C; Wed, 5 Dec 2007 21:43:48 +0100 (CET) Message-ID: <47570D85.90904@tm.uka.de> Date: Wed, 05 Dec 2007 12:43:49 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eunsoo Shim Subject: Re: [P2PSIP] client protocol architectural issues References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> In-Reply-To: <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm still not convinced we need clients. But if we decide to have clients, I also propose to use (3). We should try to avoid limiting the peer/client protocol design to P2PSIP. Regards, Ingmar Eunsoo Shim wrote: > I am opt for (3). > I don't see a reason to limit the application of the overlay to SIP. > Why would you care whether GET/PUT is used for SIP or any other > application layer protocol? > Why does option (3) make the peer protocol (and the client protocol) > more complex? > Thanks. > > Eunsoo > > On Dec 5, 2007 2:17 PM, Bruce Lowekamp wrote: >> There has been tons of discussions on the issue of "do we need a >> client protocol?" or "why do we need a client protocol?" We have the >> topic again on the agenda this afternoon. >> >> >> I want to make two assertions: >> - we need a client protocol. There's just a lot of disagreement on >> what it looks like. >> - most of the peer protocol proposals have a way of integrating >> clients at the p2p layer. there is some question as to what >> capabilities are needed at this layer. >> >> >> >> The major controversy seems to be over architecture. Three options include: >> 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP >> devices. Primary communication between a client and peer will be >> using the peer as its default outbound proxy, with any SIP extensions >> handled at the SIP layer, as in draft-li-p2psip-client-protocol. >> 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are >> SIP devices and may need to interact with a peer using P2P protocol >> GET/STORE operations. >> 3) P2PSIP peers and clients are not necessarily either SIP devices. A >> client may try to participate in the overlay by contributing storage >> to help peers or other functions generally associated with overlay >> peers without actually participating in all of the peer functionality. >> >> >> >> My personal belief is that the primary P2PSIP architecture should be (1). >> >> I think there are justifications for architecture (2), and I think >> that most/all of the protocol proposals support this. >> >> I am concerned about (3). I know that many real P2P deployments >> support this type of behavior. In one sentence, my understanding is >> that that primary motivation for these deployments is a way of making >> use of devices behind NATs. I think we (p2psip) have been looking at >> different (and more complicated) NAT traversal solutions >> (ICE/tunneling) because we believe many of our application scenarios >> don't have the same global deployment features, and we are aiming at >> topologies where most of our peers are behind NATs. (unlike >> topologies where most devices are in college dorms) >> >> Supporting (3) significantly complicates the protocol (in other >> directions than it is already complicated by other requirements such >> as NAT traversal). One of my reasons for being unsure whether we need >> it is that for P2PSIP, there are already SIP-level ways of providing >> services to the overlay. In a lot of senses, merely registering an >> AoR to peerid/ip mapping is providing services, because one of the >> fundamental roles of a SIP device is to provide SIP services. For the >> P2PSIP case, other than resource storage, what are these services that >> don't fit within the SIP model? For applications other than SIP, what >> are these services? Wouldn't any other application have its own >> application-level way of offering services? >> >> If there is consensus that it is important for the peer protocol to >> support peer/client interaction that allows the clients to provide >> storage (and maybe other peer-level functionality), I'm OK with that >> as long as it is optional and ideally not in the core draft, something >> like draft-zheng-p2psip-client-protocol. >> >> If the need for a "client protocol" for devices that provides >> "services" requires a different architecture, I'm very curious what >> they are and specific reasons why they exist and are not either >> providing SIP services or merely needing to do GET/STORE with the >> overlay to register their presence. >> >> Bruce >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 15:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01Dg-0005dX-OB; Wed, 05 Dec 2007 15:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01Df-0005Qe-Bz for p2psip@ietf.org; Wed, 05 Dec 2007 15:51:47 -0500 Received: from mxoutps1.us.army.mil ([143.69.250.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J01Da-0001eG-Td for p2psip@ietf.org; Wed, 05 Dec 2007 15:51:47 -0500 DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; b=FWRzlVvnEt9JuJe6QX+5eu/kw51SFxDfvZwxxxJFhX2ujpEs5TjKXRkZLKHsd3YabzjUqTRY3gPpNlDW7yRAQA==; Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 05 Dec 2007 20:51:41 +0000 From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 79472571:10.224.36.65:05 Dec 2007 20:51:42 +0000:$Webmail:None X-IronPort-AV: i="4.23,256,1194220800"; d="scan'208"; a="79472571:sNHT73424295" Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Wed, 05 Dec 2007 15:51:41 -0500 To: Eunsoo Shim Message-ID: Date: Wed, 05 Dec 2007 15:51:41 -0500 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en Subject: Re: [P2PSIP] client protocol architectural issues X-Accept-Language: en Priority: normal In-Reply-To: <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline [RRR] ----- Original Message ----- From: Eunsoo Shim Date: Wednesday, December 5, 2007 14:48 Subject: Re: [P2PSIP] client protocol architectural issues To: Bruce Lowekamp Cc: P2PSIP Mailing List > I am opt for (3). > I don't see a reason to limit the application of the overlay to SIP. > Why would you care whether GET/PUT is used for SIP or any other > application layer protocol? > Why does option (3) make the peer protocol (and the client protocol) > more complex? [RRR] A new protocol requires to redefine most of the properties what SIP has. Moreover, we are not developing P2P protocol per se. It has rather limited objectives per P2PSIP charter. [RRR] In this respect, P2PSIP Client protocol will also be a baby step (not entirely a new development devoid of SIP per se). [RRR] However, I will vote for option (3), if it becomes a truely a subset of P2PSIP protocol. Either way, a P2PSIP client protocol will a lightweight protocol without being a entirely NEW protocol from SIP or P2PSIP point of view. > Thanks. > > Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 15:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01KB-0005ET-S2; Wed, 05 Dec 2007 15:58:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01KA-0005E9-FI for p2psip@ietf.org; Wed, 05 Dec 2007 15:58:30 -0500 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J01K9-0002Fw-Gi for p2psip@ietf.org; Wed, 05 Dec 2007 15:58:30 -0500 Received: by an-out-0708.google.com with SMTP id d11so1190945and for ; Wed, 05 Dec 2007 12:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=qPsqBiYre9K2b5qs67S+DPsUw4W4jqXibX4bLP65B50=; b=DTYdI7Lcew43zPRRoJnk5bas+IYtSwdBPIR0I3rAmmB6I89Gu0m9QQcECyiq4fQPJeGGNqktbzwbgPt8QvdNP36JZ1GsmcSmsVpwzZ9L7hfDUOEd+AgZFRMPTfxRJoRaVdIsgalNu0UeiNkr83hoqflHUhD7gFMqWW2TW5jsi8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=cJB0VhnKzau8CqcUnnihmQToVbBp6zt+tILRjJNry6Ns0QpmdEni/8UcNocRAbrfik1aC9YrnWo+HKfZIs82+lSGhIvJXZVLR9W0p1tWYcgq19drj+oJwwCKi/GAgAhmknlbd+sWBUIQ0nwM+SxoS5JOpgJ6TiXNkGfuNySooSU= Received: by 10.142.48.14 with SMTP id v14mr1309310wfv.1196888308115; Wed, 05 Dec 2007 12:58:28 -0800 (PST) Received: by 10.142.132.18 with HTTP; Wed, 5 Dec 2007 12:58:28 -0800 (PST) Message-ID: <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> Date: Wed, 5 Dec 2007 12:58:28 -0800 From: "Bruce Lowekamp" To: "Eunsoo Shim" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> X-Google-Sender-Auth: a534f9ad4ba395bc X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Neither 1, 2, or 3 restrict the use of the overlay to SIP. 1 simply says that any application protocol, whatever it is, will have an application protocol way of communicating with a device that knows about the overlay. 2 says that whatever the application is, the application will be able to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL provide connectivity if the target is behind a NAT. 3 says that there is some need for these nodes to interact at a more basic, non-application way, that is not simply doing location for that application. It has nothing to do with non-SIP, it means that whatever the application is, it's non-application. Bruce On 12/5/07, Eunsoo Shim wrote: > I am opt for (3). > I don't see a reason to limit the application of the overlay to SIP. > Why would you care whether GET/PUT is used for SIP or any other > application layer protocol? > Why does option (3) make the peer protocol (and the client protocol) > more complex? > Thanks. > > Eunsoo > > On Dec 5, 2007 2:17 PM, Bruce Lowekamp wrote: > > There has been tons of discussions on the issue of "do we need a > > client protocol?" or "why do we need a client protocol?" We have the > > topic again on the agenda this afternoon. > > > > > > I want to make two assertions: > > - we need a client protocol. There's just a lot of disagreement on > > what it looks like. > > - most of the peer protocol proposals have a way of integrating > > clients at the p2p layer. there is some question as to what > > capabilities are needed at this layer. > > > > > > > > The major controversy seems to be over architecture. Three options include: > > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > > devices. Primary communication between a client and peer will be > > using the peer as its default outbound proxy, with any SIP extensions > > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > > SIP devices and may need to interact with a peer using P2P protocol > > GET/STORE operations. > > 3) P2PSIP peers and clients are not necessarily either SIP devices. A > > client may try to participate in the overlay by contributing storage > > to help peers or other functions generally associated with overlay > > peers without actually participating in all of the peer functionality. > > > > > > > > My personal belief is that the primary P2PSIP architecture should be (1). > > > > I think there are justifications for architecture (2), and I think > > that most/all of the protocol proposals support this. > > > > I am concerned about (3). I know that many real P2P deployments > > support this type of behavior. In one sentence, my understanding is > > that that primary motivation for these deployments is a way of making > > use of devices behind NATs. I think we (p2psip) have been looking at > > different (and more complicated) NAT traversal solutions > > (ICE/tunneling) because we believe many of our application scenarios > > don't have the same global deployment features, and we are aiming at > > topologies where most of our peers are behind NATs. (unlike > > topologies where most devices are in college dorms) > > > > Supporting (3) significantly complicates the protocol (in other > > directions than it is already complicated by other requirements such > > as NAT traversal). One of my reasons for being unsure whether we need > > it is that for P2PSIP, there are already SIP-level ways of providing > > services to the overlay. In a lot of senses, merely registering an > > AoR to peerid/ip mapping is providing services, because one of the > > fundamental roles of a SIP device is to provide SIP services. For the > > P2PSIP case, other than resource storage, what are these services that > > don't fit within the SIP model? For applications other than SIP, what > > are these services? Wouldn't any other application have its own > > application-level way of offering services? > > > > If there is consensus that it is important for the peer protocol to > > support peer/client interaction that allows the clients to provide > > storage (and maybe other peer-level functionality), I'm OK with that > > as long as it is optional and ideally not in the core draft, something > > like draft-zheng-p2psip-client-protocol. > > > > If the need for a "client protocol" for devices that provides > > "services" requires a different architecture, I'm very curious what > > they are and specific reasons why they exist and are not either > > providing SIP services or merely needing to do GET/STORE with the > > overlay to register their presence. > > > > Bruce > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > Eunsoo > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 17:58:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03Bm-0008PI-IE; Wed, 05 Dec 2007 17:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03Bl-0008Oz-Mz for p2psip@ietf.org; Wed, 05 Dec 2007 17:57:57 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J03Bl-0006BA-F4 for p2psip@ietf.org; Wed, 05 Dec 2007 17:57:57 -0500 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lB5MvsuP005276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Dec 2007 17:57:57 -0500 (EST) Date: Wed, 5 Dec 2007 17:57:54 -0500 (EST) From: Salman Abdul Baset To: p2psip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [P2PSIP] STUN/TURN servers X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Section 5.1 of P2PP draft discusses four different ways which address the issue of discovering multiple peers providing the same service, namely, 1) Standard service name (clearly, does not work for DHTs but not necessarily an issue for unstructured protocols) 2) ReDiR (OpenDHT) 3) Random Id (specific for DHTs, initially proposed by ASP) 4) Random Walk and Learning (structured and unstructured) (Debunking some myths about structured and unstructured overlays) http://research.microsoft.com/~antr/MS/myths.pdf Of course, other approaches can be used. -salman _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 21:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06Om-00088e-Ih; Wed, 05 Dec 2007 21:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06Ol-00088M-0L for p2psip@ietf.org; Wed, 05 Dec 2007 21:23:35 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J06Oj-0007Lw-Hq for p2psip@ietf.org; Wed, 05 Dec 2007 21:23:34 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J06Od-0004Pn-Rg for ; Thu, 06 Dec 2007 03:23:33 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1J06Oa-0000Xi-RW; Thu, 06 Dec 2007 03:23:27 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 5F5A92FC00C for ; Thu, 6 Dec 2007 03:23:24 +0100 (CET) Message-ID: <47575D1B.8080603@tm.uka.de> Date: Wed, 05 Dec 2007 18:23:23 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [P2PSIP] Correction for draft-baumgart-p2psip-p2pns-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello, J. Chen just informed me about a typo in draft-baumgart-p2psip-p2pns-00. In the last figure in section 8.1 it should actually be "4.lookup(ID_Y)" and not "4.lookup(ID_X)". Thanks for reporting! Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 05 21:30:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06Vm-0007lv-Sh; Wed, 05 Dec 2007 21:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06Vl-0007lj-Js for p2psip@lists.ietf.org; Wed, 05 Dec 2007 21:30:49 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J06Vl-0007um-96 for p2psip@lists.ietf.org; Wed, 05 Dec 2007 21:30:49 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSL004CFWBCJ4@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Wed, 05 Dec 2007 18:30:48 -0800 (PST) Received: from s73602 (dhcp-17a0.ietf70.org [130.129.23.160]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSL00BZXWB69M@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Wed, 05 Dec 2007 18:30:48 -0800 (PST) Date: Wed, 05 Dec 2007 18:30:33 -0800 From: Spencer Dawkins To: p2psip@lists.ietf.org Message-id: <140001c837af$fa66ba60$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [P2PSIP] Routing overview in the Concepts draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I was sitting next to Dean during the meeting today and noticed that he had typed this into the jabber room: [1:14 PM] You knw, I don't think things like "recursive routing" have made it into the concepts document. They should. A couple of things - - I agree - Philip pointed out that I left out the "route through relay" idea - that would need to be added to the list - if I need to contribute text, please let me know. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 03:31:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0C8X-0003lP-SL; Thu, 06 Dec 2007 03:31:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0C8W-0003lG-Rr for p2psip@ietf.org; Thu, 06 Dec 2007 03:31:12 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0C8W-0007rB-1F for p2psip@ietf.org; Thu, 06 Dec 2007 03:31:12 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSM00BPDCZY4S@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 06 Dec 2007 00:31:11 -0800 (PST) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSM002QWCZWZP@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 06 Dec 2007 00:31:10 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.66.76]) by szxmc04-in.huawei.com (mshttpd); Thu, 06 Dec 2007 16:31:00 +0800 Date: Thu, 06 Dec 2007 16:31:00 +0800 From: ZhengHewen 52048 Subject: Re: [P2PSIP] client protocol architectural issues In-reply-to: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> To: Bruce Lowekamp Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, In the P2PSIP session today(maybe exactly yesterady), we reached an agreement that we need P2PSIP clients, is my understanding correct? Since P2PSIP client protocol is the logical subset of P2PSIP peer protocol, I do not think that "Supporting (3) significantly complicates the protocol", maybe I miss something, would you tell me? Personally I am in favor of (2)&(3). Maybe the real world is the combination of (1)~(3), but in (1) SIP is enough. By the way, it may be the final result which the peer protocol already support clients just like P2PP. Thanks, Hewen ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: Bruce Lowekamp Date: Thursday, December 6, 2007 3:17 am Subject: [P2PSIP] client protocol architectural issues > There has been tons of discussions on the issue of "do we need a > client protocol?" or "why do we need a client protocol?" We have the > topic again on the agenda this afternoon. > > > I want to make two assertions: > - we need a client protocol. There's just a lot of disagreement on > what it looks like. > - most of the peer protocol proposals have a way of integrating > clients at the p2p layer. there is some question as to what > capabilities are needed at this layer. > > > > The major controversy seems to be over architecture. Three > options include: > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > devices. Primary communication between a client and peer will be > using the peer as its default outbound proxy, with any SIP extensions > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > SIP devices and may need to interact with a peer using P2P protocol > GET/STORE operations. > 3) P2PSIP peers and clients are not necessarily either SIP > devices. A > client may try to participate in the overlay by contributing storage > to help peers or other functions generally associated with overlay > peers without actually participating in all of the peer functionality. > > > > My personal belief is that the primary P2PSIP architecture should > be (1). > > I think there are justifications for architecture (2), and I think > that most/all of the protocol proposals support this. > > I am concerned about (3). I know that many real P2P deployments > support this type of behavior. In one sentence, my understanding is > that that primary motivation for these deployments is a way of making > use of devices behind NATs. I think we (p2psip) have been looking at > different (and more complicated) NAT traversal solutions > (ICE/tunneling) because we believe many of our application scenarios > don't have the same global deployment features, and we are aiming at > topologies where most of our peers are behind NATs. (unlike > topologies where most devices are in college dorms) > > Supporting (3) significantly complicates the protocol (in other > directions than it is already complicated by other requirements such > as NAT traversal). One of my reasons for being unsure whether we need > it is that for P2PSIP, there are already SIP-level ways of providing > services to the overlay. In a lot of senses, merely registering an > AoR to peerid/ip mapping is providing services, because one of the > fundamental roles of a SIP device is to provide SIP services. For the > P2PSIP case, other than resource storage, what are these services that > don't fit within the SIP model? For applications other than SIP, what > are these services? Wouldn't any other application have its own > application-level way of offering services? > > If there is consensus that it is important for the peer protocol to > support peer/client interaction that allows the clients to provide > storage (and maybe other peer-level functionality), I'm OK with that > as long as it is optional and ideally not in the core draft, something > like draft-zheng-p2psip-client-protocol. > > If the need for a "client protocol" for devices that provides > "services" requires a different architecture, I'm very curious what > they are and specific reasons why they exist and are not either > providing SIP services or merely needing to do GET/STORE with the > overlay to register their presence. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 03:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0CJm-0002in-UP; Thu, 06 Dec 2007 03:42:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0CJl-0002iX-O6 for p2psip@ietf.org; Thu, 06 Dec 2007 03:42:49 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0CJk-0008Hn-TI for p2psip@ietf.org; Thu, 06 Dec 2007 03:42:49 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSM00BHDDJC4S@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 06 Dec 2007 00:42:48 -0800 (PST) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSM002JUDJ9ZP@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 06 Dec 2007 00:42:48 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [130.129.66.76]) by szxmc04-in.huawei.com (mshttpd); Thu, 06 Dec 2007 16:42:37 +0800 Date: Thu, 06 Dec 2007 16:42:37 +0800 From: ZhengHewen 52048 Subject: Re: [P2PSIP] client protocol architectural issues In-reply-to: To: Bruce Lowekamp Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Here are some supplement, any comment is appreciated. If we think that the SIP is only an usage over P2P layer as in RELOADv02(ASPv00), SIP is completely irrelevant to P2P layer, then (3) will be the true. Best regards, Hewen ----- Original Message ----- From: ZhengHewen 52048 Date: Thursday, December 6, 2007 4:31 pm Subject: Re: [P2PSIP] client protocol architectural issues > Hi, > > In the P2PSIP session today(maybe exactly yesterady), we reached > an agreement that we need P2PSIP clients, is my understanding correct? > Since P2PSIP client protocol is the logical subset of P2PSIP > peer protocol, I do not think that "Supporting (3) significantly > complicates the protocol", maybe I miss something, would you tell > me? > Personally I am in favor of (2)&(3). Maybe the real world is the > combination of (1)~(3), but in (1) SIP is enough. > By the way, it may be the final result which the peer protocol > already support clients just like P2PP. > > Thanks, > Hewen > > ****************************************************************************************** > This email and its attachments contain confidential information > from HUAWEI, which is intended only for the person or entity whose > address is listed above. Any use of the information contained > herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than > the intended recipient(s) is prohibited. If you receive this e- > mail in error, please notify the sender by phone or email > immediately and delete it! > > ***************************************************************************************** > ----- Original Message ----- > From: Bruce Lowekamp > Date: Thursday, December 6, 2007 3:17 am > Subject: [P2PSIP] client protocol architectural issues > > > There has been tons of discussions on the issue of "do we need a > > client protocol?" or "why do we need a client protocol?" We > have the > > topic again on the agenda this afternoon. > > > > > > I want to make two assertions: > > - we need a client protocol. There's just a lot of disagreement on > > what it looks like. > > - most of the peer protocol proposals have a way of integrating > > clients at the p2p layer. there is some question as to what > > capabilities are needed at this layer. > > > > > > > > The major controversy seems to be over architecture. Three > > options include: > > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > > devices. Primary communication between a client and peer will be > > using the peer as its default outbound proxy, with any SIP > extensions> handled at the SIP layer, as in draft-li-p2psip-client- > protocol.> 2) P2PSIP peers are not necessarily SIP devices. > P2PSIP clients are > > SIP devices and may need to interact with a peer using P2P protocol > > GET/STORE operations. > > 3) P2PSIP peers and clients are not necessarily either SIP > > devices. A > > client may try to participate in the overlay by contributing storage > > to help peers or other functions generally associated with overlay > > peers without actually participating in all of the peer > functionality.> > > > > > > My personal belief is that the primary P2PSIP architecture > should > > be (1). > > > > I think there are justifications for architecture (2), and I think > > that most/all of the protocol proposals support this. > > > > I am concerned about (3). I know that many real P2P deployments > > support this type of behavior. In one sentence, my > understanding is > > that that primary motivation for these deployments is a way of > making> use of devices behind NATs. I think we (p2psip) have been > looking at > > different (and more complicated) NAT traversal solutions > > (ICE/tunneling) because we believe many of our application scenarios > > don't have the same global deployment features, and we are > aiming at > > topologies where most of our peers are behind NATs. (unlike > > topologies where most devices are in college dorms) > > > > Supporting (3) significantly complicates the protocol (in other > > directions than it is already complicated by other requirements such > > as NAT traversal). One of my reasons for being unsure whether > we need > > it is that for P2PSIP, there are already SIP-level ways of providing > > services to the overlay. In a lot of senses, merely registering an > > AoR to peerid/ip mapping is providing services, because one of the > > fundamental roles of a SIP device is to provide SIP services. > For the > > P2PSIP case, other than resource storage, what are these > services that > > don't fit within the SIP model? For applications other than > SIP, what > > are these services? Wouldn't any other application have its own > > application-level way of offering services? > > > > If there is consensus that it is important for the peer protocol to > > support peer/client interaction that allows the clients to provide > > storage (and maybe other peer-level functionality), I'm OK with that > > as long as it is optional and ideally not in the core draft, > something> like draft-zheng-p2psip-client-protocol. > > > > If the need for a "client protocol" for devices that provides > > "services" requires a different architecture, I'm very curious what > > they are and specific reasons why they exist and are not either > > providing SIP services or merely needing to do GET/STORE with the > > overlay to register their presence. > > > > Bruce > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 10:02:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0IFX-0002Pt-7I; Thu, 06 Dec 2007 10:02:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0IFW-0002Pl-5J for p2psip@ietf.org; Thu, 06 Dec 2007 10:02:50 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0IFV-0002tF-6v for p2psip@ietf.org; Thu, 06 Dec 2007 10:02:49 -0500 Received: by rv-out-0910.google.com with SMTP id l15so265479rvb for ; Thu, 06 Dec 2007 07:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=as9vz8wyJD6OAVkg1fmb0UyGfJD0/HyxwXhPQmWLFTM=; b=T1bInMJnyYOWkEWgBcE/ySVA9rzqX+q8thujt4cfC13tUl7DmX/iLcTyfZcW/H8+Xsej//ZTejWwH2BaQIVInSiwKIBwEXWS4FecIhNqIzh3LWtrO8mxe2TVDSwIvBaSO+iKuFfmea1T0ityIIKoHwJX6H1VUDznkyEWUYiu1f4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SjY6SuKMdrLnTLyeAGiRfLni5brIWjpMsFSN/n8nP8AqTOiDG0kkn9b5GSUXXjAxR6Jv7drvqRdFRRmyrIY6Q/yySE+cbRh+jHtyteL4gdtGUKAZzsDXIODhpFe07yIDnRFkJPqRivny0fWsK5U6rsEKCudYQBL3fQ6BUFsx29k= Received: by 10.141.50.17 with SMTP id c17mr2005834rvk.1196953366948; Thu, 06 Dec 2007 07:02:46 -0800 (PST) Received: by 10.141.40.5 with HTTP; Thu, 6 Dec 2007 07:02:46 -0800 (PST) Message-ID: <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> Date: Thu, 6 Dec 2007 10:02:46 -0500 From: "Eunsoo Shim" To: "Bruce Lowekamp" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If this subject has been resolved in the meeting already, please never mind. Otherwise.... On Dec 5, 2007 3:58 PM, Bruce Lowekamp wrote: > Neither 1, 2, or 3 restrict the use of the overlay to SIP. > > 1 simply says that any application protocol, whatever it is, will have > an application protocol way of communicating with a device that knows > about the overlay. > I don't quite understand this sentence. > 2 says that whatever the application is, the application will be able > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL > provide connectivity if the target is behind a NAT. > > 3 says that there is some need for these nodes to interact at a more > basic, non-application way, that is not simply doing location for that > application. It has nothing to do with non-SIP, it means that > whatever the application is, it's non-application. > I don't understand this either. Would you mind elaborating the above (1) and (3)? Thanks. Eunsoo > > On 12/5/07, Eunsoo Shim wrote: > > I am opt for (3). > > I don't see a reason to limit the application of the overlay to SIP. > > Why would you care whether GET/PUT is used for SIP or any other > > application layer protocol? > > Why does option (3) make the peer protocol (and the client protocol) > > more complex? > > Thanks. > > > > Eunsoo > > > > On Dec 5, 2007 2:17 PM, Bruce Lowekamp wrote: > > > There has been tons of discussions on the issue of "do we need a > > > client protocol?" or "why do we need a client protocol?" We have the > > > topic again on the agenda this afternoon. > > > > > > > > > I want to make two assertions: > > > - we need a client protocol. There's just a lot of disagreement on > > > what it looks like. > > > - most of the peer protocol proposals have a way of integrating > > > clients at the p2p layer. there is some question as to what > > > capabilities are needed at this layer. > > > > > > > > > > > > The major controversy seems to be over architecture. Three options include: > > > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > > > devices. Primary communication between a client and peer will be > > > using the peer as its default outbound proxy, with any SIP extensions > > > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > > > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > > > SIP devices and may need to interact with a peer using P2P protocol > > > GET/STORE operations. > > > 3) P2PSIP peers and clients are not necessarily either SIP devices. A > > > client may try to participate in the overlay by contributing storage > > > to help peers or other functions generally associated with overlay > > > peers without actually participating in all of the peer functionality. > > > > > > > > > > > > My personal belief is that the primary P2PSIP architecture should be (1). > > > > > > I think there are justifications for architecture (2), and I think > > > that most/all of the protocol proposals support this. > > > > > > I am concerned about (3). I know that many real P2P deployments > > > support this type of behavior. In one sentence, my understanding is > > > that that primary motivation for these deployments is a way of making > > > use of devices behind NATs. I think we (p2psip) have been looking at > > > different (and more complicated) NAT traversal solutions > > > (ICE/tunneling) because we believe many of our application scenarios > > > don't have the same global deployment features, and we are aiming at > > > topologies where most of our peers are behind NATs. (unlike > > > topologies where most devices are in college dorms) > > > > > > Supporting (3) significantly complicates the protocol (in other > > > directions than it is already complicated by other requirements such > > > as NAT traversal). One of my reasons for being unsure whether we need > > > it is that for P2PSIP, there are already SIP-level ways of providing > > > services to the overlay. In a lot of senses, merely registering an > > > AoR to peerid/ip mapping is providing services, because one of the > > > fundamental roles of a SIP device is to provide SIP services. For the > > > P2PSIP case, other than resource storage, what are these services that > > > don't fit within the SIP model? For applications other than SIP, what > > > are these services? Wouldn't any other application have its own > > > application-level way of offering services? > > > > > > If there is consensus that it is important for the peer protocol to > > > support peer/client interaction that allows the clients to provide > > > storage (and maybe other peer-level functionality), I'm OK with that > > > as long as it is optional and ideally not in the core draft, something > > > like draft-zheng-p2psip-client-protocol. > > > > > > If the need for a "client protocol" for devices that provides > > > "services" requires a different architecture, I'm very curious what > > > they are and specific reasons why they exist and are not either > > > providing SIP services or merely needing to do GET/STORE with the > > > overlay to register their presence. > > > > > > Bruce > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > -- > > Eunsoo > > > > > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 10:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0IHj-0003Dr-A8; Thu, 06 Dec 2007 10:05:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0IHh-0003Dd-WA for p2psip@ietf.org; Thu, 06 Dec 2007 10:05:06 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0IHd-00056H-6d for p2psip@ietf.org; Thu, 06 Dec 2007 10:05:05 -0500 Received: by rv-out-0910.google.com with SMTP id l15so266389rvb for ; Thu, 06 Dec 2007 07:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YTGFuhnEGcN3RsdeklSPSJd4IxXJSSfhm1jgYXHlJTA=; b=yH+ikSqsnJXUCBHn+Yvd/CssFVzkm8dRKcll4geKqlGqY33BPvc/t84TF2CoJb+o7fdHsp0CtlUZRutfUtCeMtowkkuJG334m2E8lzxHjWFDgji+ggcIecAJbX+vff+zZLb1b9/dB2J2Rwd9vjNOUWkpm5BYIMPKH9/2F12aVAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B33KNGmXTQFQ+QzRvroSjWGlrj5gFdaE1n2JIjetBc9QTkBCrlwIwYVN/SQDj0pQqktMbx9oc+gI6wCPt26rc4MmUHKHIIZ6cCA+l0iKIEDHDCz3eLX1LMPWQkVxrehXNZ1jyWFMNdj//56MERsxYqcvcBxM3Xp4w7KiSDyCdts= Received: by 10.140.133.11 with SMTP id g11mr2010367rvd.1196953499746; Thu, 06 Dec 2007 07:04:59 -0800 (PST) Received: by 10.141.40.5 with HTTP; Thu, 6 Dec 2007 07:04:59 -0800 (PST) Message-ID: <7b683f3f0712060704j5a0ee027x44e53c5f5d991b45@mail.gmail.com> Date: Thu, 6 Dec 2007 10:04:59 -0500 From: "Eunsoo Shim" To: "ZhengHewen 52048" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 6, 2007 3:31 AM, ZhengHewen 52048 wrote: > Hi, > > In the P2PSIP session today(maybe exactly yesterady), we reached an agreement that we need P2PSIP clients, is my understanding correct? Glad to hear this! > Since P2PSIP client protocol is the logical subset of P2PSIP peer protocol, I do not think that "Supporting (3) significantly complicates the protocol", maybe I miss something, would you tell me? > Personally I am in favor of (2)&(3). Maybe the real world is the combination of (1)~(3), but in (1) SIP is enough. > By the way, it may be the final result which the peer protocol already support clients just like P2PP. > I also think this is going to be the case more often than not. Thanks. Eunsoo > ----- Original Message ----- > From: Bruce Lowekamp > Date: Thursday, December 6, 2007 3:17 am > Subject: [P2PSIP] client protocol architectural issues > > > There has been tons of discussions on the issue of "do we need a > > client protocol?" or "why do we need a client protocol?" We have the > > topic again on the agenda this afternoon. > > > > > > I want to make two assertions: > > - we need a client protocol. There's just a lot of disagreement on > > what it looks like. > > - most of the peer protocol proposals have a way of integrating > > clients at the p2p layer. there is some question as to what > > capabilities are needed at this layer. > > > > > > > > The major controversy seems to be over architecture. Three > > options include: > > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > > devices. Primary communication between a client and peer will be > > using the peer as its default outbound proxy, with any SIP extensions > > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > > SIP devices and may need to interact with a peer using P2P protocol > > GET/STORE operations. > > 3) P2PSIP peers and clients are not necessarily either SIP > > devices. A > > client may try to participate in the overlay by contributing storage > > to help peers or other functions generally associated with overlay > > peers without actually participating in all of the peer functionality. > > > > > > > > My personal belief is that the primary P2PSIP architecture should > > be (1). > > > > I think there are justifications for architecture (2), and I think > > that most/all of the protocol proposals support this. > > > > I am concerned about (3). I know that many real P2P deployments > > support this type of behavior. In one sentence, my understanding is > > that that primary motivation for these deployments is a way of making > > use of devices behind NATs. I think we (p2psip) have been looking at > > different (and more complicated) NAT traversal solutions > > (ICE/tunneling) because we believe many of our application scenarios > > don't have the same global deployment features, and we are aiming at > > topologies where most of our peers are behind NATs. (unlike > > topologies where most devices are in college dorms) > > > > Supporting (3) significantly complicates the protocol (in other > > directions than it is already complicated by other requirements such > > as NAT traversal). One of my reasons for being unsure whether we need > > it is that for P2PSIP, there are already SIP-level ways of providing > > services to the overlay. In a lot of senses, merely registering an > > AoR to peerid/ip mapping is providing services, because one of the > > fundamental roles of a SIP device is to provide SIP services. For the > > P2PSIP case, other than resource storage, what are these services that > > don't fit within the SIP model? For applications other than SIP, what > > are these services? Wouldn't any other application have its own > > application-level way of offering services? > > > > If there is consensus that it is important for the peer protocol to > > support peer/client interaction that allows the clients to provide > > storage (and maybe other peer-level functionality), I'm OK with that > > as long as it is optional and ideally not in the core draft, something > > like draft-zheng-p2psip-client-protocol. > > > > If the need for a "client protocol" for devices that provides > > "services" requires a different architecture, I'm very curious what > > they are and specific reasons why they exist and are not either > > providing SIP services or merely needing to do GET/STORE with the > > overlay to register their presence. > > > > Bruce > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 11:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0K0K-000294-IW; Thu, 06 Dec 2007 11:55:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0K0J-00028v-Jg for p2psip@lists.ietf.org; Thu, 06 Dec 2007 11:55:15 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0K0J-0005oe-DL for p2psip@lists.ietf.org; Thu, 06 Dec 2007 11:55:15 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSN00JF10C26Y@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Thu, 06 Dec 2007 08:55:14 -0800 (PST) Received: from s73602 (dhcp-16f7.ietf70.org [130.129.22.247]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSN00EJF0BZVX@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Thu, 06 Dec 2007 08:55:14 -0800 (PST) Date: Thu, 06 Dec 2007 08:55:02 -0800 From: Spencer Dawkins To: p2psip@lists.ietf.org Message-id: <00b101c83828$bf0237a0$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [P2PSIP] Any further HIP discussion in hallways? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Jonathan that further discussion about HIP is really important. It's OK that this topic wasn't on the agenda this time, but are there any hallway discussions planned? Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 12:29:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KXk-0002No-IE; Thu, 06 Dec 2007 12:29:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KXj-0002Nj-MS for p2psip@ietf.org; Thu, 06 Dec 2007 12:29:47 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0KXj-0006o2-3J for p2psip@ietf.org; Thu, 06 Dec 2007 12:29:47 -0500 Received: by py-out-1112.google.com with SMTP id d32so1365261pye for ; Thu, 06 Dec 2007 09:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=raZWjILLeMQpYCTmPxpKEMRpopjtdrdnl1B2AMyQdmY=; b=wZRrzH3eSdQnW8Td1NCVngofw/GUeS4Iagr8yydQ+YNevBSluEZoXNNPbBYM04C5XTVftGR6HRwTfbTX2jAkaGm6lkrpCtpLPkjKRYjwlPJFf0I9mZRk6yZxSaDv+/1sLjQwuVA1JJ3tOhz9IRRfgTvcYpr18F7n+K5h55SmKtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eAH/mgApNbyEGSVF48Fy0ko6eAug1CFYkpTULy7gKr2RDKXkg0FSIFXiO2aPZX4vuiZiQ18kPl3PEBKgFv1h2cMYe2PpJgvL/HbHDpLnn1H0yfSTcBMXwEqfwfDFWyaDb5RXrWlhNdokuDPD8fCuQE2EwwMO9HwAgOmc7SydBEQ= Received: by 10.142.212.19 with SMTP id k19mr1773285wfg.1196962185932; Thu, 06 Dec 2007 09:29:45 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 6 Dec 2007 09:29:45 -0800 (PST) Message-ID: <20d2bdfb0712060929k7613a7e9g3881fc5382966735@mail.gmail.com> Date: Thu, 6 Dec 2007 09:29:45 -0800 From: "Bruce Lowekamp" To: "ZhengHewen 52048" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> X-Google-Sender-Auth: 33c5a0bcd0be2ce9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 6, 2007 12:31 AM, ZhengHewen 52048 wrote: > Hi, > > In the P2PSIP session today(maybe exactly yesterady), we reached an agreement that we need P2PSIP clients, is my understanding correct? > Since P2PSIP client protocol is the logical subset of P2PSIP peer protocol, I do not think that "Supporting (3) significantly complicates the protocol", maybe I miss something, would you tell me? Normally when a peer decides it is responsible for a resource id, it pulls it from its database and returns it. If the clients are able to contribute storage (i.e. 3), the peer must realize that it is responsible, look in its database for the location between itself and its clients, and route the query to the particular client. Depending on the protocol, it may need to do something to the response before it's routed back to the requester. The "client protocol" must also now support communication between the clients and the peer to register their resources, to migrate them between the peer and the various clients, etc. Possibly including replication for large numbers of clients, etc. None of these options are insurmountable (in fact there are existence proofs). But they complicate the protocol more than simple support for get/put (2). > Personally I am in favor of (2)&(3). Maybe the real world is the combination of (1)~(3), but in (1) SIP is enough. > By the way, it may be the final result which the peer protocol already support clients just like P2PP. All of the protocol proposals already support clients, at least 2. > > Here are some supplement, any comment is appreciated. > If we think that the SIP is only an usage over P2P layer as in RELOADv02(ASPv00), SIP is completely irrelevant to P2P layer, then (3) will be the true. > We agreed that there would be a client protocol and proposals should be designed to support it, but I believe we decided to defer a decision as to the exact scope of the features (e.g. 2's minimal client or 3's more powerful client). Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 12:39:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kgm-0002yy-CO; Thu, 06 Dec 2007 12:39:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kgl-0002r4-Kz for p2psip@ietf.org; Thu, 06 Dec 2007 12:39:07 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Kgl-0007Xj-9v for p2psip@ietf.org; Thu, 06 Dec 2007 12:39:07 -0500 Received: by nz-out-0506.google.com with SMTP id n1so112298nzf for ; Thu, 06 Dec 2007 09:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=nU1OvEjNCjxBB6+KFO+Si4ad2YuO943UuPYlEYVFZAw=; b=hevrmbET9QziXz1a01SBdO1qAhBvkt/t90/m/ZVz3TtD5qNO9wZrnC4PwPMP5Hg66vry7Cax5vlmXYZPa8Ldnp1xQAyNtEF7mTjO+v+ba0t0hHjFe43bhOlzCf6smu2r3N0ZTgMIMob8lwfg0M9vrslo3wJf/I/WwzmkuCwFIVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=R2AUPvWa8v46Xde9IHbln0r7h4OldaAt8gRe/UL/IwU5nkG/71YFn1r7SzIlWHODmBk5pvbFiUqH4rOarX3jD2QyuZDRZYwnX5u1gLlJRx8glPNHFennuREL95UqjyP8682UdxO/0Oom0TSRk77uaULrXJ8CPR/ejWN6ekebhGw= Received: by 10.142.112.5 with SMTP id k5mr1773530wfc.1196962746208; Thu, 06 Dec 2007 09:39:06 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 6 Dec 2007 09:39:06 -0800 (PST) Message-ID: <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> Date: Thu, 6 Dec 2007 09:39:06 -0800 From: "Bruce Lowekamp" To: "Eunsoo Shim" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> X-Google-Sender-Auth: eb65d3d62dd0fcf8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 6, 2007 7:02 AM, Eunsoo Shim wrote: > On Dec 5, 2007 3:58 PM, Bruce Lowekamp wrote: > > Neither 1, 2, or 3 restrict the use of the overlay to SIP. > > > > 1 simply says that any application protocol, whatever it is, will have > > an application protocol way of communicating with a device that knows > > about the overlay. > > > I don't quite understand this sentence. > For P2PSIP, one option for "clients" is essentially for the peer to be acting as a proxy for clients that speak only SIP and be totally unaware of the overlay. Other protocols will likely have their own way of using the peer as a client without being aware of the overlay. > > 2 says that whatever the application is, the application will be able > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL > > provide connectivity if the target is behind a NAT. > > > > 3 says that there is some need for these nodes to interact at a more > > basic, non-application way, that is not simply doing location for that > > application. It has nothing to do with non-SIP, it means that > > whatever the application is, it's non-application. > > > I don't understand this either. 2 is clients use the overlay's get/put. So they know the overlay exists and speak the p2p protocol, but don't provide storage to the overlay, they just use it to resolve lookups. 3 says that the clients will need to do more than just simple get/put. Trying to contribute storage to the peer would be the most obvious example of this. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 12:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kpu-0002HL-Cx; Thu, 06 Dec 2007 12:48:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kpt-0002ER-7T for p2psip@ietf.org; Thu, 06 Dec 2007 12:48:33 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Kpr-00020t-Nf for p2psip@ietf.org; Thu, 06 Dec 2007 12:48:33 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0Kpo-00029I-Ht for ; Thu, 06 Dec 2007 18:48:31 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1J0Kpl-0008Va-IQ; Thu, 06 Dec 2007 18:48:28 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 20FC32FC070 for ; Thu, 6 Dec 2007 18:48:24 +0100 (CET) Message-ID: <475835E7.2010906@tm.uka.de> Date: Thu, 06 Dec 2007 09:48:23 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [P2PSIP] Discussion about several P2PNS issues X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Unfortunately there was no time yesterday to present and discuss the P2PNS draft. Until now I have received only little feedback on the draft and therefore would like to discuss several issues on the list: 1) Generic Architecture with KBR/DHT seperation 2) Two-Stage Name Resolution 3) KBR and DHT Security beyond nodeID generation I've started new threads for each of these topics on the list and are also available for face-to-face meetings until Friday evening. If there is any interest we should investigate if some of these aspects could be merged into the P2PP or RELOAD drafts. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 12:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kt3-0003tK-QK; Thu, 06 Dec 2007 12:51:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kt2-0003tB-V5 for p2psip@ietf.org; Thu, 06 Dec 2007 12:51:49 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Kt2-0000Uq-DI for p2psip@ietf.org; Thu, 06 Dec 2007 12:51:48 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0Ksy-0002dC-Er for ; Thu, 06 Dec 2007 18:51:47 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1J0Ksv-0003Et-Dn; Thu, 06 Dec 2007 18:51:44 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 03B332FC070 for ; Thu, 6 Dec 2007 18:51:40 +0100 (CET) Message-ID: <475836AB.5040107@tm.uka.de> Date: Thu, 06 Dec 2007 09:51:39 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [P2PSIP] Generic Architecture with KBR/DHT separation X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The P2PNS draft proposes a modular architecure for the peer protocol based on the paper "Towards a Common API for Structured Peer-to-Peer Overlays" by F. Dabek and B. Zhao and P. Druschel and I. Stoica. For P2PNS this results in three layer: Key Based Routing (KBR): Route a message through the overlay to a destination key (route/lookup interface). Distributed Hash Table (DHT): Provides distributed storage of data records by using the KBR layer (put/get interface). Name Service/Cache: Uses the KBR/DHT layer to resolve SIP AoRs to IP addresses (register/resolve interface). In my opinion this architecture has the following benefits: - Each of these layers can be easily reused for other applications than P2PSIP (e.g. KBR is also useful for application layer multicast). The name service can be reused for distributed DNS or HIT resolution. - The KBR route/lookup interface provides a native solution to send messages to nodeIDs. Compared to adding this functionality on top of the DHT layer (like OpenDHT's ReDir does) the KBR approach is a cleaner and more efficient solution. - If you want to support different overlay topologies you only have to change the KBR layer (the complete distributed data storage layer is independent of the overlay topology). - The CommonAPI approach is used by most of the current P2P simulators like OverSim, PlanetSim or Overlay Weaver. Designing a CommonAPI compatible peer protocol would make simulations of the peer protocol much easier. Are there any concerns about using the CommonAPI for the peer protocol? Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 12:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kv6-0005rO-1W; Thu, 06 Dec 2007 12:53:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kv4-0005rF-2a for p2psip@ietf.org; Thu, 06 Dec 2007 12:53:54 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Kv3-0002VA-Oh for p2psip@ietf.org; Thu, 06 Dec 2007 12:53:54 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0Kv0-00030b-Rt for ; Thu, 06 Dec 2007 18:53:53 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1J0Kux-0003QB-O2; Thu, 06 Dec 2007 18:53:50 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 49E202FC070 for ; Thu, 6 Dec 2007 18:53:47 +0100 (CET) Message-ID: <47583729.7000605@tm.uka.de> Date: Thu, 06 Dec 2007 09:53:45 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [P2PSIP] KBR and DHT Security beyond nodeID generation X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The current security discussion was mainly focused on the secure generation of nodeIDs to limit Sybil/Eclipse attacks. The P2PNS draft proposes several additional security mechanisms, namely: KBR layer: - Routing over disjoint paths - Secure routing table maintenance (currently only for Kademlia) DHT layer: - Replication on neighbor nodes - Owner pushes records to all replicating nodes - Replicating nodes pull records to handle churn (majority vote) - Unique AoRs (only one AoR per key allowed) - Prevention of insertion DoS attacks Some of these are only slightly ripped in the current draft. Is there any interest in discussing threats beyond nodeID generation? Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 13:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L7l-0000R8-JB; Thu, 06 Dec 2007 13:07:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L7k-0000MC-AQ for p2psip@ietf.org; Thu, 06 Dec 2007 13:07:00 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0L7i-0003gV-1q for p2psip@ietf.org; Thu, 06 Dec 2007 13:07:00 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0L7c-0005aw-PS for ; Thu, 06 Dec 2007 19:06:57 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1J0L7Z-0005RS-Po; Thu, 06 Dec 2007 19:06:52 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 58BDC2FC070 for ; Thu, 6 Dec 2007 19:06:49 +0100 (CET) Message-ID: <47583A37.6020608@tm.uka.de> Date: Thu, 06 Dec 2007 10:06:47 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [P2PSIP] Two-Stage Name Resolution X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The P2PNS draft proposes to use a two stage approach to resolve AoRs to IP addresses. 1. Resolve AoR -> NodeID (DHT layer) 2. Resolve NodeID -> IP (KBR layer) This is motivated by some locator/ID split architectures. The nodeID is used as location independent identifier which is efficiently resolved to the current location (IP address) by the KBR layer. The benefit of this design is a mostly static (AoR, NodeID) binding in the DHT. This could be important if IP address often change and modification of DHT records is expensive due to security mechanisms (replication and majority votes). Probably it depends on the application scenario which of the two alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) performs better. In my opinion we should at least try to keep the peer protocol flexible enough to support both alternatives. Any comments? Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 13:18:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LIb-0004w1-Gx; Thu, 06 Dec 2007 13:18:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LIa-0004tz-Rt for p2psip@ietf.org; Thu, 06 Dec 2007 13:18:12 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LIa-0002yg-Cp for p2psip@ietf.org; Thu, 06 Dec 2007 13:18:12 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 06 Dec 2007 10:18:06 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB6II4nT012182; Thu, 6 Dec 2007 10:18:04 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lB6II3FV028226; Thu, 6 Dec 2007 10:18:04 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 10:18:03 -0800 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 Subject: RE: [P2PSIP] Two-Stage Name Resolution Date: Thu, 6 Dec 2007 10:17:18 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3B5@namail5.corp.adobe.com> In-Reply-To: <47583A37.6020608@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Two-Stage Name Resolution Thread-Index: Acg4MtgqWq+mONmgScSwOu0HUhhr4AAAN4ew References: <47583A37.6020608@tm.uka.de> From: "Henry Sinnreich" To: "Ingmar Baumgart" , "P2PSIP Mailing List" X-OriginalArrivalTime: 06 Dec 2007 18:18:03.0521 (UTC) FILETIME=[575CBF10:01C83834] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Please forgive my na=EFve question: Could a similar technique be deployed to have a forking-like behavior? Forking in SIP is has proven to have all kinds of problems and some = replacement functionality in P2PSIP is fascinating me. Henry -----Original Message----- From: Ingmar Baumgart [mailto:baumgart@tm.uka.de]=20 Sent: Thursday, December 06, 2007 10:07 AM To: P2PSIP Mailing List Subject: [P2PSIP] Two-Stage Name Resolution The P2PNS draft proposes to use a two stage approach to resolve AoRs to IP addresses. 1. Resolve AoR -> NodeID (DHT layer) 2. Resolve NodeID -> IP (KBR layer) This is motivated by some locator/ID split architectures. The nodeID is used as location independent identifier which is efficiently resolved to the current location (IP address) by the KBR layer. The benefit of this design is a mostly static (AoR, NodeID) binding in the DHT. This could be important if IP address often change and modification of DHT records is expensive due to security mechanisms (replication and majority votes). Probably it depends on the application scenario which of the two alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) performs better. In my opinion we should at least try to keep the peer protocol flexible enough to support both alternatives. Any comments? Regards, Ingmar --=20 Dipl.-Inform. Ingmar Baumgart Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 13:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LSy-0002md-Hi; Thu, 06 Dec 2007 13:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LSw-0002mW-OG for p2psip@ietf.org; Thu, 06 Dec 2007 13:28:54 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LSu-0005aZ-Ml for p2psip@ietf.org; Thu, 06 Dec 2007 13:28:54 -0500 Received: by rv-out-0910.google.com with SMTP id l15so334471rvb for ; Thu, 06 Dec 2007 10:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7QeTijCWAIDdcfMMTT3bFP1Re0uekQKJdXhEOHsirIk=; b=eN86oBVWOCToG/Rs0ONDsAwh3q2a+JMnizqfMi1tXqSyYqj1IWc519/JbEYSS5HfuLC3UUnoXEQhCKSmv6rhv3qlrk8XwUFuJn0aFuMHEyfDueZozqdVO03QrWKgYD1NGpn/7a9qB6o+cudLLkXEo4NRhkXXERzuIjMDBnRBqaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SVhbZhzYthC6X3fNhUkl2mlpmhp6b6pokG2fhUAX3bhcE64y4sVnYxRxy0JFwmsHJNSbiy1J7Lj/Fv2vgcikkHwcfIYlFMj2rSH10oivNvGdpLkz/jmA9qgl0AejRWZswCf2tV828dlDlYaBPBQ2rLPLzUxACnq+WAalt1+fU3E= Received: by 10.140.251.1 with SMTP id y1mr2154476rvh.1196965727534; Thu, 06 Dec 2007 10:28:47 -0800 (PST) Received: by 10.141.40.5 with HTTP; Thu, 6 Dec 2007 10:28:47 -0800 (PST) Message-ID: <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> Date: Thu, 6 Dec 2007 13:28:47 -0500 From: "Eunsoo Shim" To: "Bruce Lowekamp" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 6, 2007 12:39 PM, Bruce Lowekamp wrote: > On Dec 6, 2007 7:02 AM, Eunsoo Shim wrote: > > On Dec 5, 2007 3:58 PM, Bruce Lowekamp wrote: > > > Neither 1, 2, or 3 restrict the use of the overlay to SIP. > > > > > > 1 simply says that any application protocol, whatever it is, will have > > > an application protocol way of communicating with a device that knows > > > about the overlay. > > > > > I don't quite understand this sentence. > > > > For P2PSIP, one option for "clients" is essentially for the peer to be > acting as a proxy for clients that speak only SIP and be totally > unaware of the overlay. Other protocols will likely have their own > way of using the peer as a client without being aware of the overlay. > This is a problem with removing the concept of Clients in the overlay layer. If there is the Client node type, application protocols don't need to have their own way to support client-like devices. > > > > 2 says that whatever the application is, the application will be able > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL > > > provide connectivity if the target is behind a NAT. > > > > > > 3 says that there is some need for these nodes to interact at a more > > > basic, non-application way, that is not simply doing location for that > > > application. It has nothing to do with non-SIP, it means that > > > whatever the application is, it's non-application. > > > > > I don't understand this either. > > 2 is clients use the overlay's get/put. So they know the overlay > exists and speak the p2p protocol, but don't provide storage to the > overlay, they just use it to resolve lookups. > > 3 says that the clients will need to do more than just simple get/put. > Trying to contribute storage to the peer would be the most obvious > example of this. > (2) and (3) have nothing to do with whether some nodes in the overlay layer may or may not be coupled with SIP entities. What you are talking about is whether the Clients will do in the overlay layer more than just using the overlay with GET/PUT. Thanks. -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 13:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LTk-0003YL-AL; Thu, 06 Dec 2007 13:29:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LTj-0003Xs-C5 for p2psip@ietf.org; Thu, 06 Dec 2007 13:29:43 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LTi-0003zu-QC for p2psip@ietf.org; Thu, 06 Dec 2007 13:29:43 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0LTf-0000US-Ij; Thu, 06 Dec 2007 19:29:42 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1J0LTc-0002B5-K5; Thu, 06 Dec 2007 19:29:39 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 010EF2FC070; Thu, 6 Dec 2007 19:29:35 +0100 (CET) Message-ID: <47583F8E.9080804@tm.uka.de> Date: Thu, 06 Dec 2007 10:29:34 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Two-Stage Name Resolution References: <47583A37.6020608@tm.uka.de> <24CCCC428EFEA2469BF046DB3C7A8D223AE3B5@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3B5@namail5.corp.adobe.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org An AoR in the DHT could be bound to several nodeIDs or IP addresses. But probably there will be exactly the same problems as with native SIP forking. Please note that this is independent of the two stage approach (you could simply store a "AoR to multiple IPs" mapping in the DHT). Regards, Ingmar Henry Sinnreich wrote: > Please forgive my naïve question: > > Could a similar technique be deployed to have a forking-like behavior? > > Forking in SIP is has proven to have all kinds of problems and some replacement functionality in P2PSIP is fascinating me. > > Henry > > -----Original Message----- > From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] > Sent: Thursday, December 06, 2007 10:07 AM > To: P2PSIP Mailing List > Subject: [P2PSIP] Two-Stage Name Resolution > > The P2PNS draft proposes to use a two stage approach to resolve AoRs to > IP addresses. > > 1. Resolve AoR -> NodeID (DHT layer) > 2. Resolve NodeID -> IP (KBR layer) > > This is motivated by some locator/ID split architectures. > The nodeID is used as location independent identifier which is > efficiently resolved to the current location (IP address) by the KBR > layer. The benefit of this design is a mostly static (AoR, NodeID) > binding in the DHT. This could be important if IP address often change > and modification of DHT records is expensive due to security mechanisms > (replication and majority votes). > > Probably it depends on the application scenario which of the two > alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) > performs better. > > In my opinion we should at least try to keep the peer protocol flexible > enough to support both alternatives. > > Any comments? > > Regards, > Ingmar > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 13:36:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LaT-0004WT-Um; Thu, 06 Dec 2007 13:36:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LaS-0004WM-Vi for p2psip@lists.ietf.org; Thu, 06 Dec 2007 13:36:40 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LaR-0006LS-Ll for p2psip@lists.ietf.org; Thu, 06 Dec 2007 13:36:40 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J0LZr-0002wv-2w for p2psip@lists.ietf.org; Thu, 06 Dec 2007 13:36:04 -0500 In-Reply-To: <00b101c83828$bf0237a0$f7168182@china.huawei.com> References: <00b101c83828$bf0237a0$f7168182@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Any further HIP discussion in hallways? Date: Thu, 6 Dec 2007 10:36:46 -0800 To: p2psip@lists.ietf.org X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org For anyone who is interested in HIP for P2PSIP, I suggest coming to the HIP RG meeting today (Thursday) at 1300. I will be discussing the current efforts, and there are two other discussions on the agenda. - Philip On 6-Dec-07, at 08:55 , Spencer Dawkins wrote: > I agree with Jonathan that further discussion about HIP is really > important. > > It's OK that this topic wasn't on the agenda this time, but are > there any hallway discussions planned? > > Spencer > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 13:39:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lck-0002Em-5P; Thu, 06 Dec 2007 13:39:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lci-0002EB-Ig for p2psip@lists.ietf.org; Thu, 06 Dec 2007 13:39:00 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Lci-0006VU-9A for p2psip@lists.ietf.org; Thu, 06 Dec 2007 13:39:00 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J0Lch-0006Mk-2r for p2psip@lists.ietf.org; Thu, 06 Dec 2007 13:39:00 -0500 In-Reply-To: <2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> References: <00b101c83828$bf0237a0$f7168182@china.huawei.com> <2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Any further HIP discussion in hallways? Date: Thu, 6 Dec 2007 10:39:07 -0800 To: p2psip@lists.ietf.org X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If there are people who would like to discuss this at this IETF meeting, then please send me an e-mail. We might be able to discuss this early tomorrow morning. - Philip On 6-Dec-07, at 10:36 , Philip Matthews wrote: > For anyone who is interested in HIP for P2PSIP, I suggest coming to > the HIP RG meeting today (Thursday) at 1300. > I will be discussing the current efforts, and there are two other > discussions on the agenda. > > - Philip > > On 6-Dec-07, at 08:55 , Spencer Dawkins wrote: > >> I agree with Jonathan that further discussion about HIP is really >> important. >> >> It's OK that this topic wasn't on the agenda this time, but are >> there any hallway discussions planned? >> >> Spencer >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 14:00:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LxM-0003BN-UH; Thu, 06 Dec 2007 14:00:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LxL-0003BC-JF for p2psip@ietf.org; Thu, 06 Dec 2007 14:00:19 -0500 Received: from wr-out-0506.google.com ([64.233.184.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LxL-0006TT-7U for p2psip@ietf.org; Thu, 06 Dec 2007 14:00:19 -0500 Received: by wr-out-0506.google.com with SMTP id 68so278471wra for ; Thu, 06 Dec 2007 11:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=pk0zG1oUAsunggVVsfMkvCq3F7wIMHdPyMzr3vpCpUA=; b=iMXGG6BJWZxtn58YL7Phnik0xsrJ03hJeGdek/9z5xmR3HxswwQ+gujmggdIBGBD3XBAZidLpW8n9+SFBK1EY8N98WjTt8OGESHlWhtupSb22KJVeXeBhs/2fglc9gjGq2G2kjl3fqW7srIAY9OLrOwM4JFRCrKf/YjHkna0dvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DCK7YNbklVl6h6ayvcNZ0Te6ICgGJTYOMGv1HWZcJ+rTmnXTm/zNmcxBiv4guucj8AdeaP9nvN1sNiguWwuBZpdKzFDdi6yFUGlIvtLbHCSwJeefo7bsBjv0r5WLyO83/FpVtvoetuED39h1k4lJBtBmhRcA1sKoAOthAfWo8Xc= Received: by 10.142.111.14 with SMTP id j14mr1852859wfc.1196967618109; Thu, 06 Dec 2007 11:00:18 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 6 Dec 2007 11:00:18 -0800 (PST) Message-ID: <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> Date: Thu, 6 Dec 2007 11:00:18 -0800 From: "Bruce Lowekamp" To: "Eunsoo Shim" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> X-Google-Sender-Auth: 557550a282ebe46a X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 6, 2007 10:28 AM, Eunsoo Shim wrote: > On Dec 6, 2007 12:39 PM, Bruce Lowekamp wrote: > > For P2PSIP, one option for "clients" is essentially for the peer to be > > acting as a proxy for clients that speak only SIP and be totally > > unaware of the overlay. > > Other protocols will likely have their own > > way of using the peer as a client without being aware of the overlay. > > > > This is a problem with removing the concept of Clients in the overlay layer. > If there is the Client node type, application protocols don't need to > have their own way to support client-like devices. > My point is very simple. Most applications that have been discussed already exist before a p2p version has been created. So they already have this protocol. > > > > > > 2 says that whatever the application is, the application will be able > > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL > > > > provide connectivity if the target is behind a NAT. > > > > > > > > 3 says that there is some need for these nodes to interact at a more > > > > basic, non-application way, that is not simply doing location for that > > > > application. It has nothing to do with non-SIP, it means that > > > > whatever the application is, it's non-application. > > > > > > > I don't understand this either. > > > > 2 is clients use the overlay's get/put. So they know the overlay > > exists and speak the p2p protocol, but don't provide storage to the > > overlay, they just use it to resolve lookups. > > > > 3 says that the clients will need to do more than just simple get/put. > > Trying to contribute storage to the peer would be the most obvious > > example of this. > > > > (2) and (3) have nothing to do with whether some nodes in the overlay > layer may or may not be coupled with SIP entities. What you are > talking about is whether the Clients will do in the overlay layer more > than just using the overlay with GET/PUT. Exactly. SIP (since it's what we're chartered for) is just the primary working example of an application. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 14:16:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MD2-0006zR-I6; Thu, 06 Dec 2007 14:16:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MD1-0006zM-TR for p2psip@ietf.org; Thu, 06 Dec 2007 14:16:32 -0500 Received: from nz-out-0506.google.com ([64.233.162.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0MD1-0007qC-HP for p2psip@ietf.org; Thu, 06 Dec 2007 14:16:31 -0500 Received: by nz-out-0506.google.com with SMTP id n1so142395nzf for ; Thu, 06 Dec 2007 11:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=p3l67hwkTmKX6gZFT8fsZ/qJ5guTjcSUItq5SAMnLnk=; b=YYSukQAay9MtLnkxXaENfhatWQ7GTDMQkvBpsEi5pTJHx5FwFu+JtHZ+D+o6vW25VRuKxoRGdM/F249s40laNBWH1vQJhdZVVCWK2697C7rusb3za8oI+5lZkfeHFWK3aIxUKaMtNsehVEscMBTuIsjswn0sBwDnh3lNO+NVUp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lzUmE3oUn7i3dVRnDZk88PhQP3WQpZhj725KrL/v4boMBUgdQuRG8DnueIZYKn+KWPEM9Wl/HRmp2jNWfshpBlZhHw4un+sfzZ06WsdrTmtCHABuC8q9VwYFZFp3s2RvRkrqeZUvQ6qS9JW+iMtY4pPhTB6dOsKB275hQjGFx+U= Received: by 10.142.165.9 with SMTP id n9mr1860594wfe.1196968590732; Thu, 06 Dec 2007 11:16:30 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 6 Dec 2007 11:16:30 -0800 (PST) Message-ID: <20d2bdfb0712061116x74464efdg3c7de530aaea8c48@mail.gmail.com> Date: Thu, 6 Dec 2007 11:16:30 -0800 From: "Bruce Lowekamp" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] Two-Stage Name Resolution In-Reply-To: <47583A37.6020608@tm.uka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47583A37.6020608@tm.uka.de> X-Google-Sender-Auth: 33f3ba912bf72e67 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm concerned about any proposal that restricts resolution to ultimately be a mapping of AoR to IP address. (technically the Common API paper says transport address, of which it says IP is only an example.) There are examples of URI->URI mapping, URI->PeerID (where peerid is the final result because there is not direct IP connectivity), and other combinations with small or large resources being returned. reload-02 uses the term "seed" to indicate that the initial item is not necessarily an AoR or even a URI. I haven't fully digested all the implications in p2pns, but I'm concerned that it appears to restrict the range of mappings that are available. Bruce On Dec 6, 2007 10:06 AM, Ingmar Baumgart wrote: > The P2PNS draft proposes to use a two stage approach to resolve AoRs to > IP addresses. > > 1. Resolve AoR -> NodeID (DHT layer) > 2. Resolve NodeID -> IP (KBR layer) > > This is motivated by some locator/ID split architectures. > The nodeID is used as location independent identifier which is > efficiently resolved to the current location (IP address) by the KBR > layer. The benefit of this design is a mostly static (AoR, NodeID) > binding in the DHT. This could be important if IP address often change > and modification of DHT records is expensive due to security mechanisms > (replication and majority votes). > > Probably it depends on the application scenario which of the two > alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) > performs better. > > In my opinion we should at least try to keep the peer protocol flexible > enough to support both alternatives. > > Any comments? > > Regards, > Ingmar > > -- > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 14:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Mnk-0003yg-Is; Thu, 06 Dec 2007 14:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Mnj-0003yW-8K for p2psip@ietf.org; Thu, 06 Dec 2007 14:54:27 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Mni-0003f5-LC for p2psip@ietf.org; Thu, 06 Dec 2007 14:54:27 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 06 Dec 2007 11:54:16 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lB6JsDnT027900; Thu, 6 Dec 2007 11:54:15 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lB6JrkFn008297; Thu, 6 Dec 2007 11:54:12 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 04:54:00 +0900 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 Subject: RE: [P2PSIP] Generic Architecture with KBR/DHT separation Date: Thu, 6 Dec 2007 11:52:32 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3B7@namail5.corp.adobe.com> In-Reply-To: <475836AB.5040107@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Generic Architecture with KBR/DHT separation Thread-Index: Acg4MLEwnkYidCypRcqKAzO9LexSegAD9C0g References: <475836AB.5040107@tm.uka.de> From: "Henry Sinnreich" To: "Ingmar Baumgart" , "P2PSIP Mailing List" X-OriginalArrivalTime: 06 Dec 2007 19:54:00.0431 (UTC) FILETIME=[BEBF7FF0:01C83841] X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > "Towards a Common API for Structured Peer-to-Peer > Overlays" by F. Dabek and B. Zhao and P. Druschel and I. Stoica. This is the reference that explains the "p2p-natural" API and interface = levels that I have mentioned during the meeting when arguing for a = broader view of what a client should do and my position on the = "SIP-natural" interface mentioned by Phil Matthews, if I have understood = Phil correctly. Phil? I suggest the authors of the concepts draft and everybody else to review = this document and please advise. http://oceanstore.cs.berkeley.edu/publications/papers/pdf/iptps03-api.pdf= =20 Henry -----Original Message----- From: Ingmar Baumgart [mailto:baumgart@tm.uka.de]=20 Sent: Thursday, December 06, 2007 9:52 AM To: P2PSIP Mailing List Subject: [P2PSIP] Generic Architecture with KBR/DHT separation The P2PNS draft proposes a modular architecure for the peer protocol based on the paper "Towards a Common API for Structured Peer-to-Peer Overlays" by F. Dabek and B. Zhao and P. Druschel and I. Stoica. For P2PNS this results in three layer: Key Based Routing (KBR): Route a message through the overlay to a destination key (route/lookup interface). Distributed Hash Table (DHT): Provides distributed storage of data records by using the KBR layer (put/get interface). Name Service/Cache: Uses the KBR/DHT layer to resolve SIP AoRs to IP addresses (register/resolve interface). In my opinion this architecture has the following benefits: - Each of these layers can be easily reused for other applications than P2PSIP (e.g. KBR is also useful for application layer multicast). The name service can be reused for distributed DNS or HIT resolution. - The KBR route/lookup interface provides a native solution to send messages to nodeIDs. Compared to adding this functionality on top of the DHT layer (like OpenDHT's ReDir does) the KBR approach is a cleaner and more efficient solution. - If you want to support different overlay topologies you only have to change the KBR layer (the complete distributed data storage layer is independent of the overlay topology). - The CommonAPI approach is used by most of the current P2P simulators like OverSim, PlanetSim or Overlay Weaver. Designing a CommonAPI compatible peer protocol would make simulations of the peer protocol much easier. Are there any concerns about using the CommonAPI for the peer protocol? Regards, Ingmar --=20 Dipl.-Inform. Ingmar Baumgart Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 18:36:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QGj-0007k3-Ie; Thu, 06 Dec 2007 18:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QGi-0007jt-9f; Thu, 06 Dec 2007 18:36:36 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QGi-0004s5-2Y; Thu, 06 Dec 2007 18:36:36 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J0QGh-0005Kl-2C; Thu, 06 Dec 2007 18:36:35 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <79B539D8-C889-4117-88C0-2D7D695EB844@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: p2psip@lists.ietf.org, hipsec@ietf.org, hipsec-rg@listserv.cybertrust.com From: Philip Matthews Date: Thu, 6 Dec 2007 15:36:43 -0800 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [P2PSIP] Friday morning: HIP and P2PSIP discussion X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org There will be an informal discussion of the approach of using HIP for P2PSIP on Friday morning 8:15 - 9:00 (during breakfast time). If you are interested, meet in the hall outside Salon #1, #2, #3 (on the second floor). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 06 21:14:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SjA-0001NT-Sa; Thu, 06 Dec 2007 21:14:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Sj8-0001NE-58 for p2psip@ietf.org; Thu, 06 Dec 2007 21:14:06 -0500 Received: from py-out-1112.google.com ([64.233.166.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Sj7-00055N-Sy for p2psip@ietf.org; Thu, 06 Dec 2007 21:14:06 -0500 Received: by py-out-1112.google.com with SMTP id d32so2274451pye for ; Thu, 06 Dec 2007 18:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=VKczqQ1eSwcqxOgypRYMlN2ZZuSfyryYyQw+mjG8XkY=; b=jPSukxImYkAYV2wGUQVd0RpZt9HGjLscJZv6w05loUa3J3Ta+tjR+sUebeinboRF58FWOA8v+kezuyA7z6qNjgH7GeH/BDdw5ZLRi0C2r+w7/hVDXB8etQI9VKmbcD4+07jQQDuY92wxB1LiPoxXCPNfTzJj7xr3TGo4O8XKBds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=DkasWTBslW+AulGh7n4xxaXC5qH/xGPK5XWg9PZQDgEj41j4ZTOkkko6rqhnmWHU3i/9jHJ4T9U6dq3qZ4PTNDIVTVGmhsv0eDQX56GYArMEYWf4S9DQxC5MhVD9dL/Ab1gd+UF8U351fjsVm5ArQJxW9ymvGFx4ybHsidmTzzw= Received: by 10.64.91.15 with SMTP id o15mr5385649qbb.1196993645322; Thu, 06 Dec 2007 18:14:05 -0800 (PST) Received: by 10.65.180.16 with HTTP; Thu, 6 Dec 2007 18:14:05 -0800 (PST) Message-ID: <4d4304a00712061814g25e25d7di999c29a75b7f2da9@mail.gmail.com> Date: Thu, 6 Dec 2007 18:14:05 -0800 From: "David A. Bryan" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 7febef23f36bf772 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [P2PSIP] Meeting minutes posted X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The link below points to the minutes. Comments/corrections appreciated. Thanks! http://www3.ietf.org/proceedings/07dec/minutes/p2psip.html -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 01:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Wd9-0002po-4h; Fri, 07 Dec 2007 01:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Wd6-0002WR-Mi for p2psip@lists.ietf.org; Fri, 07 Dec 2007 01:24:08 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Wd4-0003O1-E6 for p2psip@lists.ietf.org; Fri, 07 Dec 2007 01:24:08 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id C244311DBE84; Fri, 7 Dec 2007 14:24:03 +0800 (CST) Message-ID: <006c01c83899$c27b2060$da07740a@dellwei> From: "Wei Gengyu" To: "Philip Matthews" References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> Subject: Re: [P2PSIP] Any further HIP discussion in hallways? Date: Fri, 7 Dec 2007 14:24:01 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0604715639==" Errors-To: p2psip-bounces@ietf.org --===============0604715639== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIFBoaWxpcCBhbmQgYWxsLA0KDQpJIGRvIG5vdCB0aGluayBpdCBpcyBhZGVxdWF0ZSB0byB1 c2UgSElQIGluIHRoZSBQMlBTSVAgb3ZlcmxheS4gDQoNCkZyb20gUkZDNDQyMyB3ZSBrbm93IHRo YXQgSElQIGlzIGFuIGVuaGFuY2VtZW50IGZvciBJUCBhZGRyZXNzIHRvIGJlIGEgaG9zdCBpZGVu dGlmaWVyLg0KV2hpbGUgSElQIHdhcyBzdWdnZXN0ZWQgYXQgdGhlIHBsYWNlIGJldHdlZW4gbmV0 d29yayBsYXllciBhbmQgdGhlIHRyYW5zcG9ydCBsYXllciwgDQpJIHN0aWxsIHRoaW5rIEhJUCBp cyBhbHNvIGEgbmV0d29yayBzdHVmZiBiZWNhdXNlIHRoZSBJUCBhZGRyZXNzIHdhcyBvcmlnaW5h bGx5IGRlZmluZWQgdG8gYmUgdGhlIGhvc3QgaWRlbnRpZmllci4NCg0KQ29uc2lkZXJpbmcgdGhl IFAyUFNJUCBvdmVybGF5LCBlYWNoIHBlZXIgc2hvdWxkIGJlIGlkZW50aWZpZWQgdW5pcXVlLg0K QnV0IGl0IHdvdWxkIG5vdCBiZSBkaXJlY3RseSB0aWVkIHRvIHRoZSBob3N0IGlkZW50aWZpZXIu DQpBbHRob3VnaCBlYWNoIHBlZXIgaXMgbmVjZXNzYXJ5IHRvIG1haXRhaW4gaW5mb21hdGlvbiBv ZiBtYXBwaW5nIFBlZXIgSWQgdG8gSG9zdCBJZCBvciBJUCBhZGRyZXNzLCAgDQppdHMgUGVlciBJ ZCBzaG91bGQgYmUgZ2VuZXJhdGVkIGluIGEgd2F5IGluZGVwZW50IHRvIHRoZSBIb3N0IElkLiAN Cg0KUmVnYXJzLCANCg0KR2VuZ3l1DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpG cm9tOiAiUGhpbGlwIE1hdHRoZXdzIiA8cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPg0KVG86IDxw MnBzaXBAbGlzdHMuaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDA3LCAyMDA3IDI6 MzkgQU0NClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBBbnkgZnVydGhlciBISVAgZGlzY3Vzc2lvbiBp biBoYWxsd2F5cz8NCg0KDQo+IElmIHRoZXJlIGFyZSBwZW9wbGUgd2hvIHdvdWxkIGxpa2UgdG8g ZGlzY3VzcyB0aGlzIGF0IHRoaXMgSUVURiAgDQo+IG1lZXRpbmcsIHRoZW4gcGxlYXNlIHNlbmQg bWUgYW4gZS1tYWlsLiBXZSBtaWdodCBiZSBhYmxlIHRvIGRpc2N1c3MgIA0KPiB0aGlzIGVhcmx5 IHRvbW9ycm93IG1vcm5pbmcuDQo+IA0KPiAtIFBoaWxpcA0KPiANCj4gT24gNi1EZWMtMDcsIGF0 IDEwOjM2ICwgUGhpbGlwIE1hdHRoZXdzIHdyb3RlOg0KPiANCj4+IEZvciBhbnlvbmUgd2hvIGlz IGludGVyZXN0ZWQgaW4gSElQIGZvciBQMlBTSVAsIEkgc3VnZ2VzdCBjb21pbmcgdG8gIA0KPj4g dGhlIEhJUCBSRyBtZWV0aW5nIHRvZGF5IChUaHVyc2RheSkgYXQgMTMwMC4NCj4+IEkgd2lsbCBi ZSBkaXNjdXNzaW5nIHRoZSBjdXJyZW50IGVmZm9ydHMsIGFuZCB0aGVyZSBhcmUgdHdvIG90aGVy ICANCj4+IGRpc2N1c3Npb25zIG9uIHRoZSBhZ2VuZGEuDQo+Pg0KPj4gLSBQaGlsaXANCj4+DQo+ PiBPbiA2LURlYy0wNywgYXQgMDg6NTUgLCBTcGVuY2VyIERhd2tpbnMgd3JvdGU6DQo+Pg0KPj4+ IEkgYWdyZWUgd2l0aCBKb25hdGhhbiB0aGF0IGZ1cnRoZXIgZGlzY3Vzc2lvbiBhYm91dCBISVAg aXMgcmVhbGx5ICANCj4+PiBpbXBvcnRhbnQuDQo+Pj4NCj4+PiBJdCdzIE9LIHRoYXQgdGhpcyB0 b3BpYyB3YXNuJ3Qgb24gdGhlIGFnZW5kYSB0aGlzIHRpbWUsIGJ1dCBhcmUgIA0KPj4+IHRoZXJl IGFueSBoYWxsd2F5IGRpc2N1c3Npb25zIHBsYW5uZWQ/DQo+Pj4NCj4+PiBTcGVuY2VyDQo+Pj4N Cj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPj4+IFAyUFNJUEBpZXRmLm9yZw0KPj4+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPj4+DQo+Pg0KPiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAy UFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPg== --===============0604715639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0604715639==-- From p2psip-bounces@ietf.org Fri Dec 07 08:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dHW-0005ev-3E; Fri, 07 Dec 2007 08:30:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dHV-0005Z3-8I for p2psip@lists.ietf.org; Fri, 07 Dec 2007 08:30:17 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0dHT-0004BR-80 for p2psip@lists.ietf.org; Fri, 07 Dec 2007 08:30:17 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J0dGl-0004OL-EQ; Fri, 07 Dec 2007 14:29:31 +0100 Message-ID: <47594AB9.9080704@uni-tuebingen.de> Date: Fri, 07 Dec 2007 14:29:29 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Wei Gengyu References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> In-Reply-To: <006c01c83899$c27b2060$da07740a@dellwei> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: p2psip@lists.ietf.org, Philip Matthews Subject: [P2PSIP] HIP pros and cons X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, just some comments (and maybe also questions to the HIP community who think that using HIP for P2PSIP is a good idea) - apparently, it has been currently understood that using the HIT as a peer-id is not a good idea. (due to chosen-location attacks, etc..). so what's the advantage for using HIP? - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP or any P2P application anyway. - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP overlay is running. You can just update you current Contact URI. So here again, there is no strong argument for HIP And the main problem with HIP might be: - resolving a HIT to an IP address is actually a very similar problem as resolving a SIP URI to a Contact URI. And for HIP, this can be done by adding some infrastructure, like rendez-points, registrations extensions, DNS extensions, etc.. and *this HIP infrastructure is not there yet!* You can try to resolve the HIT to an IP address using a DHT (as suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn into the same problems as for P2PSIP again. So, you're just moving the problems to some layers below. If some people think that HIP is really a great idea for P2PSIP, then it should be also clear to the P2PSIP community what are all the consequences of using HIP, which additional infra do they need for using HIP, whether they need IPSec ESP support on each node, etc. Cheers, Ali -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 10:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fPh-0005ML-7M; Fri, 07 Dec 2007 10:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fPg-0005MF-Md for p2psip@lists.ietf.org; Fri, 07 Dec 2007 10:46:52 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0fPe-0004CX-W5 for p2psip@lists.ietf.org; Fri, 07 Dec 2007 10:46:52 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0fPa-0001uZ-3I; Fri, 07 Dec 2007 16:46:49 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1J0fPW-0005GT-Td; Fri, 07 Dec 2007 16:46:45 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id D30E72FC00C; Fri, 7 Dec 2007 16:46:41 +0100 (CET) Message-ID: <47596AE0.3000303@tm.uka.de> Date: Fri, 07 Dec 2007 07:46:40 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Ali Fessi Subject: Re: [P2PSIP] HIP pros and cons References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> In-Reply-To: <47594AB9.9080704@uni-tuebingen.de> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: p2psip@lists.ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with most of your issues, but: By simply updating your Contact URI you won't get seamless voice stream connectivity. In this case HIP really could help. And it is true that with P2PSIP and HIP you have the same problem: you need some kind of distributed name resolution service. But maybe you can simply use the same name resolution service for both protocols? Regards, Ingmar Ali Fessi wrote: > Hi all, > > just some comments > > (and maybe also questions to the HIP community who think that using HIP > for P2PSIP is a good idea) > > - apparently, it has been currently understood that using the HIT as a > peer-id is not a good idea. (due to chosen-location attacks, etc..). so > what's the advantage for using HIP? > > - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP > or any P2P application anyway. > > - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP > overlay is running. You can just update you current Contact URI. So here > again, there is no strong argument for HIP > > And the main problem with HIP might be: > > - resolving a HIT to an IP address is actually a very similar problem as > resolving a SIP URI to a Contact URI. And for HIP, this can be done by > adding some infrastructure, like rendez-points, registrations > extensions, DNS extensions, etc.. and *this HIP infrastructure is not > there yet!* > > You can try to resolve the HIT to an IP address using a DHT (as > suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn > into the same problems as for P2PSIP again. So, you're just moving the > problems to some layers below. > > If some people think that HIP is really a great idea for P2PSIP, then it > should be also clear to the P2PSIP community what are all the > consequences of using HIP, which additional infra do they need for using > HIP, whether they need IPSec ESP support on each node, etc. > > > Cheers, > Ali > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 11:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fxL-0000CV-Nf; Fri, 07 Dec 2007 11:21:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0fxJ-0008WU-1Y for p2psip@lists.ietf.org; Fri, 07 Dec 2007 11:21:37 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0fxI-00075M-Dg for p2psip@lists.ietf.org; Fri, 07 Dec 2007 11:21:37 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J0fxC-0004Si-LF; Fri, 07 Dec 2007 17:21:30 +0100 Message-ID: <47597308.80303@uni-tuebingen.de> Date: Fri, 07 Dec 2007 17:21:28 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ingmar Baumgart Subject: Re: [P2PSIP] HIP pros and cons References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> <47596AE0.3000303@tm.uka.de> In-Reply-To: <47596AE0.3000303@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: p2psip@lists.ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Ingmar, please see inline Ingmar Baumgart wrote: > I agree with most of your issues, but: > > By simply updating your Contact URI you won't get seamless voice stream > connectivity. In this case HIP really could help. if you want to support mobility during a running session, you will probably have to send a (re-)INVITE message directly to the peers with whoom you're communicating. I'm not saying that you will have then seamless voice stream connectivity, but at least i don't see why the HIP UPDATE mechanism could perform better. > And it is true that with P2PSIP and HIP you have the same problem: you > need some kind of distributed name resolution service. But maybe you can > simply use the same name resolution service for both protocols? yes, you could. that would be the case if you're using something like P2PNS for the name resolution ;) but then, both the P2PSIP and the HIP lookup services will be running on top of P2PNS, independantly of each other, and it will probably not make sense that P2PSIP depends on HIP. cheers, Ali > > Regards, > Ingmar > > Ali Fessi wrote: >> Hi all, >> >> just some comments >> >> (and maybe also questions to the HIP community who think that using HIP >> for P2PSIP is a good idea) >> >> - apparently, it has been currently understood that using the HIT as a >> peer-id is not a good idea. (due to chosen-location attacks, etc..). so >> what's the advantage for using HIP? >> >> - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP >> or any P2P application anyway. >> >> - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP >> overlay is running. You can just update you current Contact URI. So here >> again, there is no strong argument for HIP >> >> And the main problem with HIP might be: >> >> - resolving a HIT to an IP address is actually a very similar problem as >> resolving a SIP URI to a Contact URI. And for HIP, this can be done by >> adding some infrastructure, like rendez-points, registrations >> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >> there yet!* >> >> You can try to resolve the HIT to an IP address using a DHT (as >> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn >> into the same problems as for P2PSIP again. So, you're just moving the >> problems to some layers below. >> >> If some people think that HIP is really a great idea for P2PSIP, then it >> should be also clear to the P2PSIP community what are all the >> consequences of using HIP, which additional infra do they need for using >> HIP, whether they need IPSec ESP support on each node, etc. >> >> >> Cheers, >> Ali >> > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 11:38:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gDm-0002ng-T4; Fri, 07 Dec 2007 11:38:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gDk-0002ES-1L for p2psip@ietf.org; Fri, 07 Dec 2007 11:38:36 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0gDj-0008KB-6S for p2psip@ietf.org; Fri, 07 Dec 2007 11:38:35 -0500 Received: by rv-out-0910.google.com with SMTP id l15so692025rvb for ; Fri, 07 Dec 2007 08:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/4l+iZxlNG7gaLssTWIVnisvYyJYeg/y5E41fnySJf4=; b=Xk3f6+AJubMsojck+jbomOT72cW5cjV0Vc7g8DqaGMq5FnEXOXYzjHZRqrtMWt/cEbtnKHzx0pk0pzzRkxNopD4a/xeNeWQGbqE6tPFcqbZbn0r18vgXNsT1Duer2+FxhzqV4nNwqWQ2JQzFCu8GqD4iQko8iEj8wgesBK0E5AY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B8NGohyxWxD2HLXXNJC+o6nJwQIyvYrv3wkfxI0VNeleXvhAp+tYXh78pgPf7tnqs69aKLqKczXKUNIIKqMq5B5lp52hEtO2DHjAwz6mp7+u2yydQBE+66pWP4Y+x+gIwNFj3PgRB/1QJaZ91Y2B5iAOLaWGjZB8Jwy4S7MPU9I= Received: by 10.141.171.6 with SMTP id y6mr2779079rvo.1197045514147; Fri, 07 Dec 2007 08:38:34 -0800 (PST) Received: by 10.141.40.5 with HTTP; Fri, 7 Dec 2007 08:38:34 -0800 (PST) Message-ID: <7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com> Date: Fri, 7 Dec 2007 11:38:34 -0500 From: "Eunsoo Shim" To: "Bruce Lowekamp" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I don't quite understand how what you wrote below is connected to your initial proposal that P2PSIP architecture should require all devices/nodes (Peers and Clients) to be coupled with SIP entities. Could you explain again the reason of your proposal? Thanks. Eunsoo On Dec 6, 2007 2:00 PM, Bruce Lowekamp wrote: > On Dec 6, 2007 10:28 AM, Eunsoo Shim wrote: > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp wrote: > > > For P2PSIP, one option for "clients" is essentially for the peer to be > > > acting as a proxy for clients that speak only SIP and be totally > > > unaware of the overlay. > > > > Other protocols will likely have their own > > > way of using the peer as a client without being aware of the overlay. > > > > > > > This is a problem with removing the concept of Clients in the overlay layer. > > If there is the Client node type, application protocols don't need to > > have their own way to support client-like devices. > > > > My point is very simple. Most applications that have been discussed > already exist before a p2p version has been created. So they already > have this protocol. > > > > > > > > > 2 says that whatever the application is, the application will be able > > > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > 3 says that there is some need for these nodes to interact at a more > > > > > basic, non-application way, that is not simply doing location for that > > > > > application. It has nothing to do with non-SIP, it means that > > > > > whatever the application is, it's non-application. > > > > > > > > > I don't understand this either. > > > > > > 2 is clients use the overlay's get/put. So they know the overlay > > > exists and speak the p2p protocol, but don't provide storage to the > > > overlay, they just use it to resolve lookups. > > > > > > 3 says that the clients will need to do more than just simple get/put. > > > Trying to contribute storage to the peer would be the most obvious > > > example of this. > > > > > > > (2) and (3) have nothing to do with whether some nodes in the overlay > > layer may or may not be coupled with SIP entities. What you are > > talking about is whether the Clients will do in the overlay layer more > > than just using the overlay with GET/PUT. > > Exactly. SIP (since it's what we're chartered for) is just the > primary working example of an application. > > Bruce > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 12:43:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hEJ-0000wo-TK; Fri, 07 Dec 2007 12:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hEI-0000wj-Hz for p2psip@ietf.org; Fri, 07 Dec 2007 12:43:14 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hEG-00051l-Ou for p2psip@ietf.org; Fri, 07 Dec 2007 12:43:14 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J0hEC-0004OU-83; Fri, 07 Dec 2007 18:43:11 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1J0hE9-0007Dc-2D; Fri, 07 Dec 2007 18:43:08 +0100 Received: from wooky.tm.uka.de (dhcp-356f.ietf70.org [130.129.53.111]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 4F8282FC00C; Fri, 7 Dec 2007 18:43:04 +0100 (CET) Message-ID: <47598626.5090301@tm.uka.de> Date: Fri, 07 Dec 2007 09:43:02 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] Two-Stage Name Resolution References: <47583A37.6020608@tm.uka.de> <20d2bdfb0712061116x74464efdg3c7de530aaea8c48@mail.gmail.com> In-Reply-To: <20d2bdfb0712061116x74464efdg3c7de530aaea8c48@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a good point. I think the two-stage approach is only a optimization for some use cases. The peer protocol should support all the different type of mappings you mentioned on DHT layer. In case this is an (AoR, NodeID) mapping you simply go for the second stage on KBR layer. Regards, Ingmar Bruce Lowekamp wrote: > I'm concerned about any proposal that restricts resolution to > ultimately be a mapping of AoR to IP address. (technically the Common > API paper says transport address, of which it says IP is only an > example.) There are examples of URI->URI mapping, URI->PeerID (where > peerid is the final result because there is not direct IP > connectivity), and other combinations with small or large resources > being returned. reload-02 uses the term "seed" to indicate that the > initial item is not necessarily an AoR or even a URI. > > I haven't fully digested all the implications in p2pns, but I'm > concerned that it appears to restrict the range of mappings that are > available. > > Bruce > > > On Dec 6, 2007 10:06 AM, Ingmar Baumgart wrote: >> The P2PNS draft proposes to use a two stage approach to resolve AoRs to >> IP addresses. >> >> 1. Resolve AoR -> NodeID (DHT layer) >> 2. Resolve NodeID -> IP (KBR layer) >> >> This is motivated by some locator/ID split architectures. >> The nodeID is used as location independent identifier which is >> efficiently resolved to the current location (IP address) by the KBR >> layer. The benefit of this design is a mostly static (AoR, NodeID) >> binding in the DHT. This could be important if IP address often change >> and modification of DHT records is expensive due to security mechanisms >> (replication and majority votes). >> >> Probably it depends on the application scenario which of the two >> alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) >> performs better. >> >> In my opinion we should at least try to keep the peer protocol flexible >> enough to support both alternatives. >> >> Any comments? >> >> Regards, >> Ingmar >> >> -- >> Dipl.-Inform. Ingmar Baumgart >> Institut für Telematik, Universität Karlsruhe (TH) >> Zirkel 2, 76128 Karlsruhe, Germany >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 13:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hcH-0003pr-M8; Fri, 07 Dec 2007 13:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hcG-0003pf-HY for p2psip@lists.ietf.org; Fri, 07 Dec 2007 13:08:00 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0hcE-0006vl-Sj for p2psip@lists.ietf.org; Fri, 07 Dec 2007 13:08:00 -0500 Received: (qmail invoked by alias); 07 Dec 2007 18:07:57 -0000 Received: from dhcp-16c7.ietf70.org (EHLO [130.129.22.199]) [130.129.22.199] by mail.gmx.net (mp004) with SMTP; 07 Dec 2007 19:07:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qmldHwO2qtraSFJDgLYdpur0tpOoZbKJnn8ypFw WhC7x2ryiP9hcq Message-ID: <47598BF9.8030402@gmx.net> Date: Fri, 07 Dec 2007 19:07:53 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ali Fessi Subject: Re: [P2PSIP] HIP pros and cons References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> In-Reply-To: <47594AB9.9080704@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: p2psip@lists.ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a very good summary, Ali. I see the usage of HIP for (P2P)SIP more as another end-to-end media security solution. Ciao Hannes Ali Fessi wrote: > Hi all, > > just some comments > > (and maybe also questions to the HIP community who think that using > HIP for P2PSIP is a good idea) > > - apparently, it has been currently understood that using the HIT as a > peer-id is not a good idea. (due to chosen-location attacks, etc..). > so what's the advantage for using HIP? > > - for NAT traversal: HIP is also doing ICE, which can be used for > P2PSIP or any P2P application anyway. > > - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP > overlay is running. You can just update you current Contact URI. So > here again, there is no strong argument for HIP > > And the main problem with HIP might be: > > - resolving a HIT to an IP address is actually a very similar problem > as resolving a SIP URI to a Contact URI. And for HIP, this can be done > by adding some infrastructure, like rendez-points, registrations > extensions, DNS extensions, etc.. and *this HIP infrastructure is not > there yet!* > > You can try to resolve the HIT to an IP address using a DHT (as > suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably > turn into the same problems as for P2PSIP again. So, you're just > moving the problems to some layers below. > > If some people think that HIP is really a great idea for P2PSIP, then > it should be also clear to the P2PSIP community what are all the > consequences of using HIP, which additional infra do they need for > using HIP, whether they need IPSec ESP support on each node, etc. > > > Cheers, > Ali > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 14:46:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j98-0000UC-01; Fri, 07 Dec 2007 14:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j97-0000U5-8C for p2psip@lists.ietf.org; Fri, 07 Dec 2007 14:46:01 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0j95-00051k-Mo for p2psip@lists.ietf.org; Fri, 07 Dec 2007 14:46:01 -0500 Received: from dhcp-17f5.ietf70.org ([130.129.23.245]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J0j94-0007Xs-25; Fri, 07 Dec 2007 14:45:58 -0500 In-Reply-To: <47594AB9.9080704@uni-tuebingen.de> References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 7 Dec 2007 11:46:05 -0800 To: Ali Fessi X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - dhcp-17f5.ietf70.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: p2psip@lists.ietf.org Subject: [P2PSIP] Re: HIP pros and cons X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A brief reply for now. See inline. - Philip On 7-Dec-07, at 05:29 , Ali Fessi wrote: > Hi all, > > just some comments > > (and maybe also questions to the HIP community who think that using > HIP for P2PSIP is a good idea) > > - apparently, it has been currently understood that using the HIT > as a peer-id is not a good idea. (due to chosen-location attacks, > etc..). so what's the advantage for using HIP? The main advantage that I see is that it allows many existing applications to run in a P2P overlay without changes, unlike all the non-HIP proposals, which require changes to your applications. In essence, HIP turns your P2P Overlay into a VPN, and so existing applications work in this VPN in much the same way they do in existing VPNs. The implementation of HIP uses VPN implementation techniques, so if you computer can run VPN software (and many OSes can) then it can run HIP. Like existing VPNs, HIP can also provide encryption between peers in the overlay. > > - for NAT traversal: HIP is also doing ICE, which can be used for > P2PSIP or any P2P application anyway. Yes, but with the non-HIP-based proposals, you have to modify your application. > > - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP > overlay is running. You can just update you current Contact URI. So > here again, there is no strong argument for HIP Err.. I would not say that mobility is easy. However, the ID/Locator split idea of HIP make mobility easier. > > And the main problem with HIP might be: > > - resolving a HIT to an IP address is actually a very similar > problem as resolving a SIP URI to a Contact URI. And for HIP, this > can be done by adding some infrastructure, like rendez-points, > registrations extensions, DNS extensions, etc.. and *this HIP > infrastructure is not there yet! > > You can try to resolve the HIT to an IP address using a DHT (as > suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably > turn into the same problems as for P2PSIP again. So, you're just > moving the problems to some layers below. > > If some people think that HIP is really a great idea for P2PSIP, > then it should be also clear to the P2PSIP community what are all > the consequences of using HIP, which additional infra do they need > for using HIP, whether they need IPSec ESP support on each node, etc. I don't think you understand how the proposals work. None of the three current HIP-based proposals require anything extra. They just use the DHT. Try reading draft-matthews-p2psip-id-loc, and look at the example in the document. I think this might be easiest way to understand what is going on. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 16:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0klE-0004VS-St; Fri, 07 Dec 2007 16:29:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0klD-0004VK-J1 for p2psip@lists.ietf.org; Fri, 07 Dec 2007 16:29:27 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0klB-0004E7-9X for p2psip@lists.ietf.org; Fri, 07 Dec 2007 16:29:27 -0500 Received: by ug-out-1314.google.com with SMTP id z38so1047913ugc for ; Fri, 07 Dec 2007 13:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SuaPEkpBTnMi4nC28AM3wnPz+4IcXwDD735kvdxuIQ0=; b=CnC247NoBsNhQHmTX4Du21XR1hExo+deHYaR9etdioJnKyHRb8sZC2k7U7QZMimZqv2KcTfixoZ7gRl+4+amL+R26HxpqTTgJvtcviuZQddqAZ85OgICtsYhL/9ucxynGrmkp0kqj18kM0ulWGoZFqg27ALCw0zcXNDhJ+2Ezd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JiqhGKRByHLnL336hEdmrGDsm5XcEhyyc6NFvquqGYJO95AOB1c9bWJDG/7HLo7I9yB5uxqguSc7+/1r/FW6P8PRObrJXgRyv3mifSBkqrNq09jU1SKu913dWgguFHfXucaIPkNQE6SnlqhsWtjQxaUYS8DX7mtDHVgZYrCX7ag= Received: by 10.66.251.3 with SMTP id y3mr2587408ugh.1197062964479; Fri, 07 Dec 2007 13:29:24 -0800 (PST) Received: by 10.67.21.19 with HTTP; Fri, 7 Dec 2007 13:29:24 -0800 (PST) Message-ID: <618e24240712071329gf86ccd2v229eb68e76ceab46@mail.gmail.com> Date: Fri, 7 Dec 2007 22:29:24 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "Philip Matthews" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: MIME-Version: 1.0 References: <00b101c83828$bf0237a0$f7168182@china.huawei.com> <2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0451678861==" Errors-To: p2psip-bounces@ietf.org --===============0451678861== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UGhpbGlwLApkb2VzIEhJUCBoYXZlIGFueSBpbXBhY3Qgb24gb3ZlcmxheXMgaW50ZXJjb25uZWN0 aW9uIChpbnRlci1kb21haW4gcm91dGluZyk/CgpUaGFua3MsClZpY3RvcgoKT24gMDcvMTIvMjAw NywgUGhpbGlwIE1hdHRoZXdzIDxwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E+IHdyb3RlOgo+IEEg YnJpZWYgcmVwbHkgZm9yIG5vdy4gU2VlIGlubGluZS4KPiAtIFBoaWxpcAo+IE9uIDctRGVjLTA3 LCBhdCAwNToyOSAsIEFsaSBGZXNzaSB3cm90ZToKPgo+ID4gSGkgYWxsLAo+ID4KPiA+IGp1c3Qg c29tZSBjb21tZW50cwo+ID4KPiA+IChhbmQgbWF5YmUgYWxzbyBxdWVzdGlvbnMgdG8gdGhlIEhJ UCBjb21tdW5pdHkgd2hvIHRoaW5rIHRoYXQgdXNpbmcKPiA+IEhJUCBmb3IgUDJQU0lQIGlzIGEg Z29vZCBpZGVhKQo+ID4KPiA+IC0gYXBwYXJlbnRseSwgaXQgaGFzIGJlZW4gY3VycmVudGx5IHVu ZGVyc3Rvb2QgdGhhdCB1c2luZyB0aGUgSElUCj4gPiBhcyBhIHBlZXItaWQgaXMgbm90IGEgZ29v ZCBpZGVhLiAoZHVlIHRvIGNob3Nlbi1sb2NhdGlvbiBhdHRhY2tzLAo+ID4gZXRjLi4pLiBzbyB3 aGF0J3MgdGhlIGFkdmFudGFnZSBmb3IgdXNpbmcgSElQPwo+Cj4gVGhlIG1haW4gYWR2YW50YWdl IHRoYXQgSSBzZWUgaXMgdGhhdCBpdCBhbGxvd3MgbWFueSBleGlzdGluZwo+IGFwcGxpY2F0aW9u cyB0byBydW4gaW4gYSBQMlAgb3ZlcmxheSB3aXRob3V0IGNoYW5nZXMsIHVubGlrZSBhbGwgdGhl Cj4gbm9uLUhJUCBwcm9wb3NhbHMsIHdoaWNoIHJlcXVpcmUgY2hhbmdlcyB0byB5b3VyIGFwcGxp Y2F0aW9ucy4gSW4KPiBlc3NlbmNlLCBISVAgdHVybnMgeW91ciBQMlAgT3ZlcmxheSBpbnRvIGEg VlBOLCBhbmQgc28gZXhpc3RpbmcKPiBhcHBsaWNhdGlvbnMgd29yayBpbiB0aGlzIFZQTiBpbiBt dWNoIHRoZSBzYW1lIHdheSB0aGV5IGRvIGluCj4gZXhpc3RpbmcgVlBOcy4gVGhlIGltcGxlbWVu dGF0aW9uIG9mIEhJUCB1c2VzIFZQTiBpbXBsZW1lbnRhdGlvbgo+IHRlY2huaXF1ZXMsIHNvIGlm IHlvdSBjb21wdXRlciBjYW4gcnVuIFZQTiBzb2Z0d2FyZSAoYW5kIG1hbnkgT1Nlcwo+IGNhbikg dGhlbiBpdCBjYW4gcnVuIEhJUC4KPgo+IExpa2UgZXhpc3RpbmcgVlBOcywgSElQIGNhbiBhbHNv IHByb3ZpZGUgZW5jcnlwdGlvbiBiZXR3ZWVuIHBlZXJzIGluCj4gdGhlIG92ZXJsYXkuCj4KPiA+ Cj4gPiAtIGZvciBOQVQgdHJhdmVyc2FsOiBISVAgaXMgYWxzbyBkb2luZyBJQ0UsIHdoaWNoIGNh biBiZSB1c2VkIGZvcgo+ID4gUDJQU0lQIG9yIGFueSBQMlAgYXBwbGljYXRpb24gYW55d2F5Lgo+ Cj4gWWVzLCBidXQgd2l0aCB0aGUgbm9uLUhJUC1iYXNlZCBwcm9wb3NhbHMsIHlvdSBoYXZlIHRv IG1vZGlmeSB5b3VyCj4gYXBwbGljYXRpb24uCj4KPiA+Cj4gPiAtIG1vYmlsaXR5IGNhbiBiZSBh Y2hpZXZlZCBieSBhIFAyUFNJUCBvdmVybGF5IGVhc2lseSBvbmNlIGEgUDJQU0lQCj4gPiBvdmVy bGF5IGlzIHJ1bm5pbmcuIFlvdSBjYW4ganVzdCB1cGRhdGUgeW91IGN1cnJlbnQgQ29udGFjdCBV UkkuIFNvCj4gPiBoZXJlIGFnYWluLCB0aGVyZSBpcyBubyBzdHJvbmcgYXJndW1lbnQgZm9yIEhJ UAo+Cj4gRXJyLi4gSSB3b3VsZCBub3Qgc2F5IHRoYXQgbW9iaWxpdHkgaXMgZWFzeS4gIEhvd2V2 ZXIsIHRoZSBJRC9Mb2NhdG9yCj4gc3BsaXQgaWRlYSBvZiBISVAgbWFrZSBtb2JpbGl0eSBlYXNp ZXIuCj4KPiA+Cj4gPiBBbmQgdGhlIG1haW4gcHJvYmxlbSB3aXRoIEhJUCBtaWdodCBiZToKPiA+ Cj4gPiAtIHJlc29sdmluZyBhIEhJVCB0byBhbiBJUCBhZGRyZXNzIGlzIGFjdHVhbGx5IGEgdmVy eSBzaW1pbGFyCj4gPiBwcm9ibGVtIGFzIHJlc29sdmluZyBhIFNJUCBVUkkgdG8gYSBDb250YWN0 IFVSSS4gQW5kIGZvciBISVAsIHRoaXMKPiA+IGNhbiBiZSBkb25lIGJ5IGFkZGluZyBzb21lIGlu ZnJhc3RydWN0dXJlLCBsaWtlIHJlbmRlei1wb2ludHMsCj4gPiByZWdpc3RyYXRpb25zIGV4dGVu c2lvbnMsIEROUyBleHRlbnNpb25zLCBldGMuLiBhbmQgKnRoaXMgSElQCj4gPiBpbmZyYXN0cnVj dHVyZSBpcyBub3QgdGhlcmUgeWV0IQo+ID4KPiA+IFlvdSBjYW4gdHJ5IHRvIHJlc29sdmUgdGhl IEhJVCB0byBhbiBJUCBhZGRyZXNzIHVzaW5nIGEgREhUIChhcwo+ID4gc3VnZ2VzdGVkIGluIGRy YWZ0LWFocmVuaG9sei1oaXByZy1kaHQtMDEgKS4gQnV0IHlvdSB3aWxsIHByb2JhYmx5Cj4gPiB0 dXJuIGludG8gdGhlIHNhbWUgcHJvYmxlbXMgYXMgZm9yIFAyUFNJUCBhZ2Fpbi4gU28sIHlvdSdy ZSBqdXN0Cj4gPiBtb3ZpbmcgdGhlIHByb2JsZW1zIHRvIHNvbWUgbGF5ZXJzIGJlbG93Lgo+ID4K PiA+IElmIHNvbWUgcGVvcGxlIHRoaW5rIHRoYXQgSElQIGlzIHJlYWxseSBhIGdyZWF0IGlkZWEg Zm9yIFAyUFNJUCwKPiA+IHRoZW4gaXQgc2hvdWxkIGJlIGFsc28gY2xlYXIgdG8gdGhlIFAyUFNJ UCBjb21tdW5pdHkgd2hhdCBhcmUgYWxsCj4gPiB0aGUgY29uc2VxdWVuY2VzIG9mIHVzaW5nIEhJ UCwgd2hpY2ggYWRkaXRpb25hbCBpbmZyYSBkbyB0aGV5IG5lZWQKPiA+IGZvciB1c2luZyBISVAs IHdoZXRoZXIgdGhleSBuZWVkIElQU2VjIEVTUCBzdXBwb3J0IG9uIGVhY2ggbm9kZSwgZXRjLgo+ Cj4KPiBJIGRvbid0IHRoaW5rIHlvdSB1bmRlcnN0YW5kIGhvdyB0aGUgcHJvcG9zYWxzIHdvcmsu IE5vbmUgb2YgdGhlCj4gdGhyZWUgY3VycmVudCBISVAtYmFzZWQgcHJvcG9zYWxzIHJlcXVpcmUg YW55dGhpbmcgZXh0cmEuIFRoZXkganVzdAo+IHVzZSB0aGUgREhULgo+Cj4gVHJ5IHJlYWRpbmcg ZHJhZnQtbWF0dGhld3MtcDJwc2lwLWlkLWxvYywgYW5kIGxvb2sgYXQgdGhlIGV4YW1wbGUgaW4K PiB0aGUgZG9jdW1lbnQuIEkgdGhpbmsgdGhpcyBtaWdodCBiZSBlYXNpZXN0IHdheSB0byB1bmRl cnN0YW5kIHdoYXQgaXMKPiBnb2luZyBvbi4KPgo+IC0gUGhpbGlwCj4KPgo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gUDJQU0lQIG1haWxpbmcgbGlz dAo+IFAyUFNJUEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3AycHNpcAo+CgoKLS0gClZpY3RvciBQYXNjdWFsIMOBdmlsYQo= --===============0451678861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0451678861==-- From p2psip-bounces@ietf.org Fri Dec 07 19:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nSQ-00041U-2B; Fri, 07 Dec 2007 19:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nSP-00041M-6A for p2psip@lists.ietf.org; Fri, 07 Dec 2007 19:22:13 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0nSN-0000GF-U7 for p2psip@lists.ietf.org; Fri, 07 Dec 2007 19:22:13 -0500 Received: from s01060018e70bfb18.wk.shawcable.net ([24.67.234.227] helo=[192.168.1.104]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J0nSM-0006KB-2d; Fri, 07 Dec 2007 19:22:11 -0500 In-Reply-To: <618e24240712071329gf86ccd2v229eb68e76ceab46@mail.gmail.com> References: <00b101c83828$bf0237a0$f7168182@china.huawei.com> <2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> <618e24240712071329gf86ccd2v229eb68e76ceab46@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0993948C-7A5F-4D58-913D-F18E35F3CE4A@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Fri, 7 Dec 2007 16:22:13 -0800 To: =?ISO-8859-1?Q?"Victor_Pascual_=C1vila"?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - s01060018e70bfb18.wk.shawcable.net ([192.168.1.104]) [24.67.234.227] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7-Dec-07, at 13:29 , Victor Pascual =C1vila wrote: > Philip, > does HIP have any impact on overlays interconnection (inter-domain =20 > routing)? > So far, we have not considered connections between two different =20 overlays. Right now, everyone seems to be assuming that this =20 connection would be made with ordinary client-server SIP. - Philip= _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 07 19:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nnU-0003In-1m; Fri, 07 Dec 2007 19:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0nnT-0003I9-6x for p2psip@ietf.org; Fri, 07 Dec 2007 19:43:59 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0nnR-0001TL-8w for p2psip@ietf.org; Fri, 07 Dec 2007 19:43:59 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 82FC22E08; Sat, 8 Dec 2007 02:43:56 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id DC3F02CD9 for ; Sat, 8 Dec 2007 02:43:49 +0200 (EET) Date: Sat, 8 Dec 2007 02:43:49 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: p2psip@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [P2PSIP] Re: HIP pros and cons X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ali Fessi wrote: > Hi all, > > just some comments > > (and maybe also questions to the HIP community who think that using HIP > for P2PSIP is a good idea) > > - apparently, it has been currently understood that using the HIT as a > peer-id is not a good idea. (due to chosen-location attacks, etc..). so > what's the advantage for using HIP? I am not sure about the issue here but does the chosen-location attack have do anything with HIP? I think it is not really a HIP specific attack, just something related to DHTs. > - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP > or any P2P application anyway. I'd disagree here. It is possible to use ICE in P2P-SIP because it is completely new application and not a legacy application. However, if you think about it architecturally, why makes P2P-SIP so special that it must burden itself with NAT traversal? Why cannot just use a NAT traversal service transparently from the lower layers? I think the designers and implementors of P2P-SIP can concentrate better to some P2P-SIP issues if NAT traversal is handled by someone else. > - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP > overlay is running. You can just update you current Contact URI. So here > again, there is no strong argument for HIP Disagree again here. Doesn't it still disconnect active phone calls? If you want to support mobility during phone calls in P2P-SIP, I'd ask the same question as before: what makes SIP such an special application that it needs its own host mobility mechanism? > And the main problem with HIP might be: > > - resolving a HIT to an IP address is actually a very similar problem as > resolving a SIP URI to a Contact URI. And for HIP, this can be done by > adding some infrastructure, like rendez-points, registrations > extensions, DNS extensions, etc.. and *this HIP infrastructure is not > there yet!* Agree partially, but I think this would make new business cases for corporations from deploying infrastructure for customers. The DNS extensions are not mandatory. You can use opportunistic mode which works in the similar leap-of-fait manner as ssh. > You can try to resolve the HIT to an IP address using a DHT (as > suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn > into the same problems as for P2PSIP again. So, you're just moving the > problems to some layers below. Well, isn't it the right layer for solving those problems? > If some people think that HIP is really a great idea for P2PSIP, then it > should be also clear to the P2PSIP community what are all the > consequences of using HIP, which additional infra do they need for using > HIP, whether they need IPSec ESP support on each node, etc. Minimal requirements are that you need some HIP relays to transport the HIP "offer/answer". Implementing NULL-ESP is trivial and supported by the HIP specs. DNS extensions are not mandatory. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 08 10:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J11Tp-0007aC-Di; Sat, 08 Dec 2007 10:20:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J11Tn-0007a7-Un for p2psip@lists.ietf.org; Sat, 08 Dec 2007 10:20:35 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J11Tl-0006dP-VS for p2psip@lists.ietf.org; Sat, 08 Dec 2007 10:20:35 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSQ005VNLA9QQ@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Sat, 08 Dec 2007 07:20:33 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSQ001EYLA424@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Sat, 08 Dec 2007 07:20:32 -0800 (PST) Date: Sat, 08 Dec 2007 09:20:15 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Re: HIP pros and cons To: p2psip@lists.ietf.org Message-id: <066401c839ad$d67ada00$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00b101c83828$bf0237a0$f7168182@china.huawei.com> <2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei> <47594AB9.9080704@uni-tuebingen.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Recognizing that we are all too stupid from lack of rest to have an intelligent conversation this weekend ... but continuing to type anyway ... :-) >> - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP >> overlay is running. You can just update you current Contact URI. So here >> again, there is no strong argument for HIP > > Err.. I would not say that mobility is easy. However, the ID/Locator > split idea of HIP make mobility easier. I agree with Philip's response here, but want to point to a related topic. A decent number of the application scenarios would benefit from multihoming, and another design goal for Bob Moskowitz-era HIP was supporting IPsec VPNs that survived path changes because IPsec only saw HITs, so when the underlying IP addresses changed, applications survived. (That's why HITs look like IPv6 addresses, by the way) This matters more in my own application scenarios of interest, and the ID/Loc split in HIP helps with this as well. Both mobility and multihoming are discussed (in the same section) in http://tools.ietf.org/html/rfc4423. People may be thinking about SIP-level or overlay-level mobility in their environments, but neither of these are attributes in the current version of the application scenarios draft. I think some of the "carrier-grade robustness" attributes could be addressed by multihoming, but I'm sure this isn't explicit in the current draft, either. I meant to say this during the talk on routing, but we only had 15 minutes and I wanted to give the working group as much precious discussion time as possible - BUT, - I'm not thinking that the application scenarios draft would even be adopted as a WG draft, and certainly would not be a prerequisite for requirements, concepts descriptions, or peer protocol proposals, BUT - It would be nice for people to think about the current draft contents, and tell us what they are thinking about, that isn't covered (like mobility, like support for survivability). http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt If you can provide a column (that describes an application scenario), or a row (that does the attribute analysis for multiple application scenarios), that would be absolutely lovely. IMO, of course. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 09 21:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1YRH-0001IP-Ti; Sun, 09 Dec 2007 21:32:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1YRG-0001IG-Gq for p2psip@ietf.org; Sun, 09 Dec 2007 21:32:10 -0500 Received: from exprod6og104.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1YRF-0002Mh-MA for p2psip@ietf.org; Sun, 09 Dec 2007 21:32:10 -0500 Received: from source ([192.150.20.142]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP; Sun, 09 Dec 2007 18:32:03 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBA2VknT001526; Sun, 9 Dec 2007 18:31:47 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBA2VWRI004667; Sun, 9 Dec 2007 18:31:45 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:31:39 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Sun, 9 Dec 2007 18:31:37 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3C5@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg5M3bej1R/8I6ZTqi1h3kCXuWtwQBmFAIg References: From: "Henry Sinnreich" To: "Miika Komu" , X-OriginalArrivalTime: 10 Dec 2007 02:31:39.0979 (UTC) FILETIME=[CB62D9B0:01C83AD4] X-Spam-Score: -4.0 (----) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > If you want to support mobility during phone calls in P2P-SIP See http://en.wikipedia.org/wiki/Media_independent_handover >I think the designers and implementors of P2P-SIP can concentrate better to >some P2P-SIP issues if NAT traversal is handled by someone else. Why cannot >just use a NAT traversal service transparently from the lower layers? I fully agree. See the link above. The P2P SIP WG is now closer IMHO to examine carefully the various proposals and meld the best features as much as possible. This will require a lot of work, both analytical comparisons and measurements. See also: http://tools.ietf.org/id/draft-ahrenholz-hiprg-dht-01.txt As for ICE/STUN/TURN vs. HIP I would not exclude a synergy between the two that can be devised, since the HIP security, mobility, multiplex, etc. and applicability for any other application protocol are hard to beat and IP also uses an ICE-like approach. http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt=20 Henry =20 -----Original Message----- From: Miika Komu [mailto:miika@iki.fi]=20 Sent: Friday, December 07, 2007 4:44 PM To: p2psip@ietf.org Subject: [P2PSIP] Re: HIP pros and cons Ali Fessi wrote: > Hi all, > > just some comments > > (and maybe also questions to the HIP community who think that using HIP > for P2PSIP is a good idea) > > - apparently, it has been currently understood that using the HIT as a > peer-id is not a good idea. (due to chosen-location attacks, etc..). so > what's the advantage for using HIP? I am not sure about the issue here but does the chosen-location attack=20 have do anything with HIP? I think it is not really a HIP specific attack,=20 just something related to DHTs. > - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP > or any P2P application anyway. I'd disagree here. It is possible to use ICE in P2P-SIP because it is=20 completely new application and not a legacy application. However, if you think about it architecturally, why makes P2P-SIP so special that it must=20 burden itself with NAT traversal? Why cannot just use a NAT traversal=20 service transparently from the lower layers? I think the designers and implementors of P2P-SIP can concentrate better to some P2P-SIP issues if NAT traversal is handled by someone else. > - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP > overlay is running. You can just update you current Contact URI. So here > again, there is no strong argument for HIP Disagree again here. Doesn't it still disconnect active phone calls? If you want to support mobility during phone calls in P2P-SIP, I'd ask the=20 same question as before: what makes SIP such an special application that it needs its own host mobility mechanism? > And the main problem with HIP might be: > > - resolving a HIT to an IP address is actually a very similar problem as > resolving a SIP URI to a Contact URI. And for HIP, this can be done by > adding some infrastructure, like rendez-points, registrations > extensions, DNS extensions, etc.. and *this HIP infrastructure is not > there yet!* Agree partially, but I think this would make new business cases for=20 corporations from deploying infrastructure for customers. The DNS extensions are not mandatory. You can use opportunistic mode which=20 works in the similar leap-of-fait manner as ssh. > You can try to resolve the HIT to an IP address using a DHT (as > suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn > into the same problems as for P2PSIP again. So, you're just moving the > problems to some layers below. Well, isn't it the right layer for solving those problems? > If some people think that HIP is really a great idea for P2PSIP, then it > should be also clear to the P2PSIP community what are all the > consequences of using HIP, which additional infra do they need for using > HIP, whether they need IPSec ESP support on each node, etc. Minimal requirements are that you need some HIP relays to transport the=20 HIP "offer/answer". Implementing NULL-ESP is trivial and supported by the=20 HIP specs. DNS extensions are not mandatory. --=20 Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 09 21:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1YRW-0001hx-H6; Sun, 09 Dec 2007 21:32:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1YRU-0001WP-Ff for p2psip@lists.ietf.org; Sun, 09 Dec 2007 21:32:24 -0500 Received: from exprod6og101.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1YRT-0002N2-6W for p2psip@lists.ietf.org; Sun, 09 Dec 2007 21:32:24 -0500 Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Sun, 09 Dec 2007 18:32:04 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBA2TV12025671; Sun, 9 Dec 2007 18:29:31 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBA2VWRG004667; Sun, 9 Dec 2007 18:31:44 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 11:31:42 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP pros and cons Date: Sun, 9 Dec 2007 18:28:11 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3C8@namail5.corp.adobe.com> In-Reply-To: <47597308.80303@uni-tuebingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP pros and cons Thread-Index: Acg47UJCN8INYjwuTjatdMRM/lfC2wB5oQrg References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei><47594AB9.9080704@uni-tuebingen.de> <47596AE0.3000303@tm.uka.de> <47597308.80303@uni-tuebingen.de> From: "Henry Sinnreich" To: "Ali Fessi" , "Ingmar Baumgart" X-OriginalArrivalTime: 10 Dec 2007 02:31:42.0167 (UTC) FILETIME=[CCB0B670:01C83AD4] X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: p2psip@lists.ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >if you want to support mobility during a running session, you will=20 >probably have to send a (re-)INVITE message directly to the peers with=20 >whoom you're communicating. This is a narrow SIP-centric view and probably not optimal either. See rather http://en.wikipedia.org/wiki/Media_independent_handover how it can be done at L2 for all IP sessions. Henry -----Original Message----- From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de]=20 Sent: Friday, December 07, 2007 8:21 AM To: Ingmar Baumgart Cc: p2psip@lists.ietf.org; Philip Matthews Subject: Re: [P2PSIP] HIP pros and cons Hi Ingmar, please see inline Ingmar Baumgart wrote: > I agree with most of your issues, but: >=20 > By simply updating your Contact URI you won't get seamless voice stream > connectivity. In this case HIP really could help. if you want to support mobility during a running session, you will=20 probably have to send a (re-)INVITE message directly to the peers with=20 whoom you're communicating. I'm not saying that you will have then=20 seamless voice stream connectivity, but at least i don't see why the HIP UPDATE mechanism could perform better. > And it is true that with P2PSIP and HIP you have the same problem: you > need some kind of distributed name resolution service. But maybe you can > simply use the same name resolution service for both protocols? yes, you could. that would be the case if you're using something like=20 P2PNS for the name resolution ;) but then, both the P2PSIP and the HIP lookup services will be running on top of P2PNS, independantly of each other, and it will probably not make sense that P2PSIP depends on HIP. cheers, Ali >=20 > Regards, > Ingmar >=20 > Ali Fessi wrote: >> Hi all, >> >> just some comments >> >> (and maybe also questions to the HIP community who think that using HIP >> for P2PSIP is a good idea) >> >> - apparently, it has been currently understood that using the HIT as a >> peer-id is not a good idea. (due to chosen-location attacks, etc..). so >> what's the advantage for using HIP? >> >> - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP >> or any P2P application anyway. >> >> - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP >> overlay is running. You can just update you current Contact URI. So here >> again, there is no strong argument for HIP >> >> And the main problem with HIP might be: >> >> - resolving a HIT to an IP address is actually a very similar problem as >> resolving a SIP URI to a Contact URI. And for HIP, this can be done by >> adding some infrastructure, like rendez-points, registrations >> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >> there yet!* >> >> You can try to resolve the HIT to an IP address using a DHT (as >> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn >> into the same problems as for P2PSIP again. So, you're just moving the >> problems to some layers below. >> >> If some people think that HIP is really a great idea for P2PSIP, then it >> should be also clear to the P2PSIP community what are all the >> consequences of using HIP, which additional infra do they need for using >> HIP, whether they need IPSec ESP support on each node, etc. >> >> >> Cheers, >> Ali >> >=20 --=20 Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 10:04:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kAp-0007xi-Dr; Mon, 10 Dec 2007 10:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kAn-0007wm-Tr for p2psip@lists.ietf.org; Mon, 10 Dec 2007 10:03:57 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1kAl-0002nI-Pb for p2psip@lists.ietf.org; Mon, 10 Dec 2007 10:03:57 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J1k9t-00061L-7T; Mon, 10 Dec 2007 16:03:01 +0100 Message-ID: <475D5522.50701@uni-tuebingen.de> Date: Mon, 10 Dec 2007 16:02:58 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] HIP pros and cons References: <00b101c83828$bf0237a0$f7168182@china.huawei.com><2EED884C-C9C6-40B5-B848-D5FDCFCAF57B@magma.ca> <6D9CC90E-2B2A-4237-8087-23E115E8F769@magma.ca> <006c01c83899$c27b2060$da07740a@dellwei><47594AB9.9080704@uni-tuebingen.de> <47596AE0.3000303@tm.uka.de> <47597308.80303@uni-tuebingen.de> <24CCCC428EFEA2469BF046DB3C7A8D223AE3C8@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3C8@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: p2psip@lists.ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Henry, Henry Sinnreich wrote: >> if you want to support mobility during a running session, you will >> probably have to send a (re-)INVITE message directly to the peers with >> whoom you're communicating. > > This is a narrow SIP-centric view and probably not optimal either. > > See rather http://en.wikipedia.org/wiki/Media_independent_handover how > it can be done at L2 for all IP sessions. thanks for you hint. Of course there are many possibilities to achieve mobility. But it is difficult to say, which one is the best. The discussion was about the pros and cons of using HIP as underlying protocol for P2PSIP. and I was arguing that HIP can be useful for mobility, but you can also achieve mobility with different approaches, e.g. SIP. and IMHO, it is not obvious to show why HIP mobility is more efficient. Cheers, Ali > > Henry > > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] > Sent: Friday, December 07, 2007 8:21 AM > To: Ingmar Baumgart > Cc: p2psip@lists.ietf.org; Philip Matthews > Subject: Re: [P2PSIP] HIP pros and cons > > Hi Ingmar, > > please see inline > > Ingmar Baumgart wrote: >> I agree with most of your issues, but: >> >> By simply updating your Contact URI you won't get seamless voice > stream >> connectivity. In this case HIP really could help. > > if you want to support mobility during a running session, you will > probably have to send a (re-)INVITE message directly to the peers with > whoom you're communicating. I'm not saying that you will have then > seamless voice stream connectivity, but at least i don't see why the HIP > > UPDATE mechanism could perform better. > >> And it is true that with P2PSIP and HIP you have the same problem: you >> need some kind of distributed name resolution service. But maybe you > can >> simply use the same name resolution service for both protocols? > > yes, you could. that would be the case if you're using something like > P2PNS for the name resolution ;) > > but then, both the P2PSIP and the HIP lookup services will be running on > > top of P2PNS, independantly of each other, and it will probably not make > > sense that P2PSIP depends on HIP. > > cheers, > Ali > > >> Regards, >> Ingmar >> >> Ali Fessi wrote: >>> Hi all, >>> >>> just some comments >>> >>> (and maybe also questions to the HIP community who think that using > HIP >>> for P2PSIP is a good idea) >>> >>> - apparently, it has been currently understood that using the HIT as > a >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). > so >>> what's the advantage for using HIP? >>> >>> - for NAT traversal: HIP is also doing ICE, which can be used for > P2PSIP >>> or any P2P application anyway. >>> >>> - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP >>> overlay is running. You can just update you current Contact URI. So > here >>> again, there is no strong argument for HIP >>> >>> And the main problem with HIP might be: >>> >>> - resolving a HIT to an IP address is actually a very similar problem > as >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done > by >>> adding some infrastructure, like rendez-points, registrations >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >>> there yet!* >>> >>> You can try to resolve the HIT to an IP address using a DHT (as >>> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably > turn >>> into the same problems as for P2PSIP again. So, you're just moving > the >>> problems to some layers below. >>> >>> If some people think that HIP is really a great idea for P2PSIP, then > it >>> should be also clear to the P2PSIP community what are all the >>> consequences of using HIP, which additional infra do they need for > using >>> HIP, whether they need IPSec ESP support on each node, etc. >>> >>> >>> Cheers, >>> Ali >>> > > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 10:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kMQ-0003aD-4M; Mon, 10 Dec 2007 10:15:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kMP-0003Vj-Bc for p2psip@ietf.org; Mon, 10 Dec 2007 10:15:57 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1kMO-0006ID-LJ for p2psip@ietf.org; Mon, 10 Dec 2007 10:15:57 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J1kMI-00061r-JP; Mon, 10 Dec 2007 16:15:50 +0100 Message-ID: <475D5824.103@uni-tuebingen.de> Date: Mon, 10 Dec 2007 16:15:48 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Miika, thanks for the clarification. one question: what happens if the HIP identifier colludes with an IPv6 address that is reserved for multicast, anycast, or e.g. local IPv6 addresses? or does HIP generate several public/private pairs until it finds a good one? Cheers, Ali Miika Komu wrote: > Ali Fessi wrote: > >> Hi all, >> >> just some comments >> >> (and maybe also questions to the HIP community who think that using HIP >> for P2PSIP is a good idea) >> >> - apparently, it has been currently understood that using the HIT as a >> peer-id is not a good idea. (due to chosen-location attacks, etc..). so >> what's the advantage for using HIP? > > I am not sure about the issue here but does the chosen-location attack > have do anything with HIP? I think it is not really a HIP specific > attack, just something related to DHTs. > >> - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP >> or any P2P application anyway. > > I'd disagree here. It is possible to use ICE in P2P-SIP because it is > completely new application and not a legacy application. However, if you > think about it architecturally, why makes P2P-SIP so special that it > must burden itself with NAT traversal? Why cannot just use a NAT > traversal service transparently from the lower layers? > > I think the designers and implementors of P2P-SIP can concentrate better > to some P2P-SIP issues if NAT traversal is handled by someone else. > >> - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP >> overlay is running. You can just update you current Contact URI. So here >> again, there is no strong argument for HIP > > Disagree again here. Doesn't it still disconnect active phone calls? > > If you want to support mobility during phone calls in P2P-SIP, I'd ask > the same question as before: what makes SIP such an special application > that it needs its own host mobility mechanism? > >> And the main problem with HIP might be: >> >> - resolving a HIT to an IP address is actually a very similar problem as >> resolving a SIP URI to a Contact URI. And for HIP, this can be done by >> adding some infrastructure, like rendez-points, registrations >> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >> there yet!* > > Agree partially, but I think this would make new business cases for > corporations from deploying infrastructure for customers. > > The DNS extensions are not mandatory. You can use opportunistic mode > which works in the similar leap-of-fait manner as ssh. > >> You can try to resolve the HIT to an IP address using a DHT (as >> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn >> into the same problems as for P2PSIP again. So, you're just moving the >> problems to some layers below. > > Well, isn't it the right layer for solving those problems? > >> If some people think that HIP is really a great idea for P2PSIP, then it >> should be also clear to the P2PSIP community what are all the >> consequences of using HIP, which additional infra do they need for using >> HIP, whether they need IPSec ESP support on each node, etc. > > Minimal requirements are that you need some HIP relays to transport the > HIP "offer/answer". Implementing NULL-ESP is trivial and supported by > the HIP specs. DNS extensions are not mandatory. > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 11:56:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lvs-0006hB-W0; Mon, 10 Dec 2007 11:56:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lvs-0006h5-2K for p2psip@ietf.org; Mon, 10 Dec 2007 11:56:40 -0500 Received: from el-out-1112.google.com ([209.85.162.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1lvp-0005n0-Pq for p2psip@ietf.org; Mon, 10 Dec 2007 11:56:40 -0500 Received: by el-out-1112.google.com with SMTP id r23so270864elf for ; Mon, 10 Dec 2007 08:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=IgeOGfZoa85KptXIXiD5z8keMFK3kSKRrUuwwVjxBLw=; b=P9kt3Ub8qKHjGYaBYuJrK6Br3LYwiaq56y1jVBAjWGWqsOVHZxyDiolACEUdvbwrJ636IGseIJFh46TDRr1gsPe4y9/qeKn449QG4Gw5oliHhEPzrhJCxDEq3RmDGG6ZuUmdu8hK/sFDEr8McLoZGu/nmCOA2pke2AoSjUI01Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JDjqhybWIE9yr291Rpk6+h5T76E71UYHD2K/7QpPLlxDHHlE3MKe9i0q6shZd0j+YV9Gi9z47TlYLGTG4DrEIKR0IJ1D7BRwQvkSVBRopYjBUwdK060vqB0ohSGQu++LRCINLMTvPg8KJYPjwU/BFCmOBOll+x6Qs1PJBOhGMK4= Received: by 10.142.216.9 with SMTP id o9mr629694wfg.1197305796693; Mon, 10 Dec 2007 08:56:36 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 10 Dec 2007 08:56:36 -0800 (PST) Message-ID: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> Date: Mon, 10 Dec 2007 11:56:36 -0500 From: "Bruce Lowekamp" To: "Miika Komu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 84ac393fcf3d81ad X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 7, 2007 7:43 PM, Miika Komu wrote: > Ali Fessi wrote: > > - apparently, it has been currently understood that using the HIT as a > > peer-id is not a good idea. (due to chosen-location attacks, etc..). so > > what's the advantage for using HIP? > > I am not sure about the issue here but does the chosen-location attack > have do anything with HIP? I think it is not really a HIP specific attack, > just something related to DHTs. > The chosen location attack is related to the method of generating a HIT from a node-generated key. As long as the HIT can be allocated by an enrollment server (or otherwise secured so that a single node cannot generate multiple or arbitrary HITs), there isn't a security problem here. If a node must be able to generate its own HIT, then the HIT cannot be used as a replacement for the peer-id in a DHT. > > And the main problem with HIP might be: > > > > - resolving a HIT to an IP address is actually a very similar problem as > > resolving a SIP URI to a Contact URI. And for HIP, this can be done by > > adding some infrastructure, like rendez-points, registrations > > extensions, DNS extensions, etc.. and *this HIP infrastructure is not > > there yet!* > > Agree partially, but I think this would make new business cases for > corporations from deploying infrastructure for customers. > > The DNS extensions are not mandatory. You can use opportunistic mode which > works in the similar leap-of-fait manner as ssh. Surely there's an option in between "use dns" and "use leap-of-faith" of using certificate chains? > > - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP > > or any P2P application anyway. > > I'd disagree here. It is possible to use ICE in P2P-SIP because it is > completely new application and not a legacy application. However, if you > think about it architecturally, why makes P2P-SIP so special that it must > burden itself with NAT traversal? Why cannot just use a NAT traversal > service transparently from the lower layers? > > I think the designers and implementors of P2P-SIP can concentrate better > to some P2P-SIP issues if NAT traversal is handled by someone else. > > > > If some people think that HIP is really a great idea for P2PSIP, then it > > should be also clear to the P2PSIP community what are all the > > consequences of using HIP, which additional infra do they need for using > > HIP, whether they need IPSec ESP support on each node, etc. > > Minimal requirements are that you need some HIP relays to transport the > HIP "offer/answer". Implementing NULL-ESP is trivial and supported by the > HIP specs. DNS extensions are not mandatory. > (I rearranged this a little bit to bring these two issues together.) One of the confusing things about applying HIP to p2psip is the layering issues required to address the deployment scenarios for p2psip. We need it to work in an environment without provisioned DNS support for the overlay and where we cannot assume an infrastructure provider providing HIP relays. We need to be able to obtain those services from peers in the overlay. So, minimally, this means the ability to support the HIP relay functionality at the overlay layer. This is where the proposal becomes confusing, because while HIP provides a very nice abstraction on top of which to build a p2p application, it also requires that p2p application for its connectivity. I've spent some time working with Philip on how to provide support for HIP inside of a p2psip peer protocol, and I think it's entirely doable, but I think we need to be clear on how the layering works and what support is needed in both directions before deciding how to accomplish it. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 13:15:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nAK-0006ew-Ho; Mon, 10 Dec 2007 13:15:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nAK-0006ck-47 for p2psip@ietf.org; Mon, 10 Dec 2007 13:15:40 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nAJ-0007rg-Rm for p2psip@ietf.org; Mon, 10 Dec 2007 13:15:40 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSU00KPVIQ3C6@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 10 Dec 2007 10:15:39 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSU001FXIQ1JQ@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 10 Dec 2007 10:15:39 -0800 (PST) Date: Mon, 10 Dec 2007 12:15:16 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Re: HIP pros and cons To: p2psip@ietf.org Message-id: <082601c83b58$9de2b3a0$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > One of the confusing things about applying HIP to p2psip is the > layering issues required to address the deployment scenarios for > p2psip. We need it to work in an environment without provisioned DNS > support for the overlay and where we cannot assume an infrastructure > provider providing HIP relays. We need to be able to obtain those > services from peers in the overlay. So, minimally, this means the > ability to support the HIP relay functionality at the overlay layer. > This is where the proposal becomes confusing, because while HIP > provides a very nice abstraction on top of which to build a p2p > application, it also requires that p2p application for its > connectivity. > > I've spent some time working with Philip on how to provide support for > HIP inside of a p2psip peer protocol, and I think it's entirely > doable, but I think we need to be clear on how the layering works and > what support is needed in both directions before deciding how to > accomplish it. I agree completely (on both "doable" and "need to be clear on how the layering works"). At a minumum, we could figure out whether we're running SIP over HIP or HIP over SIP... :-) Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 13:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nRO-0005xN-L7; Mon, 10 Dec 2007 13:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nRN-0005oN-CG for p2psip@ietf.org; Mon, 10 Dec 2007 13:33:17 -0500 Received: from mxoutps1.us.army.mil ([143.69.250.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nRJ-0008IP-KU for p2psip@ietf.org; Mon, 10 Dec 2007 13:33:17 -0500 DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; b=oN+H0uKsWsg8bZhtIYI+wqpc3ARA/CHroZq+1cMOsnOqvHOsod1rUP6W6uMTZ818AQGpTPZYB19VIB3X+6KGdQ==; Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 10 Dec 2007 18:33:06 +0000 From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 82863280:10.224.36.65:10 Dec 2007 18:33:06 +0000:$Webmail:None X-IronPort-AV: i="4.23,277,1194220800"; d="scan'208"; a="82863280:sNHT9832114887" Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Mon, 10 Dec 2007 13:33:06 -0500 To: Spencer Dawkins Message-ID: Date: Mon, 10 Dec 2007 13:33:06 -0500 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en Subject: Re: [P2PSIP] Re: HIP pros and cons X-Accept-Language: en Priority: normal In-Reply-To: <082601c83b58$9de2b3a0$f7168182@china.huawei.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <082601c83b58$9de2b3a0$f7168182@china.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline [RRR] ----- Original Message ----- From: Spencer Dawkins Date: Monday, December 10, 2007 13:16 Subject: Re: [P2PSIP] Re: HIP pros and cons To: p2psip@ietf.org > > One of the confusing things about applying HIP to p2psip is the > > layering issues required to address the deployment scenarios for > > p2psip. We need it to work in an environment without > provisioned DNS > > support for the overlay and where we cannot assume an infrastructure > > provider providing HIP relays. We need to be able to obtain those > > services from peers in the overlay. So, minimally, this means the > > ability to support the HIP relay functionality at the overlay layer. > > This is where the proposal becomes confusing, because while HIP > > provides a very nice abstraction on top of which to build a p2p > > application, it also requires that p2p application for its > > connectivity. > > > > I've spent some time working with Philip on how to provide > support for > > HIP inside of a p2psip peer protocol, and I think it's entirely > > doable, but I think we need to be clear on how the layering > works and > > what support is needed in both directions before deciding how to > > accomplish it. > > I agree completely (on both "doable" and "need to be clear on how > the > layering works"). > > At a minumum, we could figure out whether we're running SIP over > HIP or HIP > over SIP... [RRR] Please help us to understand: What does it mean with respect to the P2PSIP protocol when do the following: SIP over HIP or HIP-over-SIP? [RRR] Are you suggesting that the P2PSIP protocol will include the above features as well as others defined in the requirement document, and the combined protocol will still be called P2PSIP? > > :-) > > Spencer > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 13:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nbd-000068-II; Mon, 10 Dec 2007 13:43:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nbc-000063-25 for p2psip@ietf.org; Mon, 10 Dec 2007 13:43:52 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nba-00004w-7k for p2psip@ietf.org; Mon, 10 Dec 2007 13:43:52 -0500 Received: by nz-out-0506.google.com with SMTP id n1so622593nzf for ; Mon, 10 Dec 2007 10:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=cmmySmQox9qkUg5U3sHVFungqDIpNAAMyZW86uOEnMQ=; b=FAkjbLlwUK+Y+ieWIKUlKq2aN16Ohy/kV9odQgIawPzYdcnj1IRB6ESx9PUg06/XZ4eI9d3ps63K2a3RXoiBLwRX2fJ91vbomhxj3jFSG+Cbzrp2UYlu7+nbble2RnVpSnfm36627VLi5gHZcV9MfZRpQ3tOwbrPNBvTXl4kA0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pLjPUpY3D+yPMVfpR1MUneyT1n+ItS5GQpNU6rZ3Un4n9gR3Cwul6d0wU1CfBnw9bhmNOkDxX2oKClaQe8HE3YOJM3RCOwFbIq62nkjVoEwBvxVoYub1xTLSR5WSPg+JomlFFshjLCf1Hk0Jd4c3/gr/OBhKS0lq+5Y1ru/7Uy4= Received: by 10.142.194.1 with SMTP id r1mr3206965wff.1197312227747; Mon, 10 Dec 2007 10:43:47 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 10 Dec 2007 10:43:47 -0800 (PST) Message-ID: <20d2bdfb0712101043qbd83a4dvc03e62249f7227f0@mail.gmail.com> Date: Mon, 10 Dec 2007 13:43:47 -0500 From: "Bruce Lowekamp" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] Two-Stage Name Resolution In-Reply-To: <47598626.5090301@tm.uka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <47583A37.6020608@tm.uka.de> <20d2bdfb0712061116x74464efdg3c7de530aaea8c48@mail.gmail.com> <47598626.5090301@tm.uka.de> X-Google-Sender-Auth: 3140ebb7d0298b57 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org How does P2PNS implement the KBR in the presence of NATs? Using HITs as NodeID has the obvious attraction that there is no mapping to an IP, but in other cases, there isn't a mapping to a single IP, thus the proposals for tunneling over the overlay or establishing a direct connection to a remote peer (identified by peerid) by using ICE. reload-01 and p2pp both propose using a set of (ice candidate) addresses but in all cases, fallback to full ice is required when those don't work. Bruce On Dec 7, 2007 12:43 PM, Ingmar Baumgart wrote: > This is a good point. I think the two-stage approach is only a > optimization for some use cases. The peer protocol should support all > the different type of mappings you mentioned on DHT layer. In case this > is an (AoR, NodeID) mapping you simply go for the second stage on KBR lay= er. > > Regards, > Ingmar > > > Bruce Lowekamp wrote: > > I'm concerned about any proposal that restricts resolution to > > ultimately be a mapping of AoR to IP address. (technically the Common > > API paper says transport address, of which it says IP is only an > > example.) There are examples of URI->URI mapping, URI->PeerID (where > > peerid is the final result because there is not direct IP > > connectivity), and other combinations with small or large resources > > being returned. reload-02 uses the term "seed" to indicate that the > > initial item is not necessarily an AoR or even a URI. > > > > I haven't fully digested all the implications in p2pns, but I'm > > concerned that it appears to restrict the range of mappings that are > > available. > > > > Bruce > > > > > > On Dec 6, 2007 10:06 AM, Ingmar Baumgart wrote: > >> The P2PNS draft proposes to use a two stage approach to resolve AoRs t= o > >> IP addresses. > >> > >> 1. Resolve AoR -> NodeID (DHT layer) > >> 2. Resolve NodeID -> IP (KBR layer) > >> > >> This is motivated by some locator/ID split architectures. > >> The nodeID is used as location independent identifier which is > >> efficiently resolved to the current location (IP address) by the KBR > >> layer. The benefit of this design is a mostly static (AoR, NodeID) > >> binding in the DHT. This could be important if IP address often change > >> and modification of DHT records is expensive due to security mechanism= s > >> (replication and majority votes). > >> > >> Probably it depends on the application scenario which of the two > >> alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) > >> performs better. > >> > >> In my opinion we should at least try to keep the peer protocol flexibl= e > >> enough to support both alternatives. > >> > >> Any comments? > >> > >> Regards, > >> Ingmar > >> > >> -- > >> Dipl.-Inform. Ingmar Baumgart > >> Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > >> Zirkel 2, 76128 Karlsruhe, Germany > >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > >> > > -- > > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 14:23:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oEI-0000rX-Ts; Mon, 10 Dec 2007 14:23:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oEI-0000rP-1P for p2psip@ietf.org; Mon, 10 Dec 2007 14:23:50 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oEH-0001Xx-BQ for p2psip@ietf.org; Mon, 10 Dec 2007 14:23:50 -0500 Received: by wr-out-0506.google.com with SMTP id 68so1353541wra for ; Mon, 10 Dec 2007 11:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=5TlMdr7QFFW02C6t77zF14fuWONSfUwR8tfoXDB84UA=; b=eL60JoZwUZsZN4/5OQVUpxn1BArFEeVjiW3GWUL6hTOwzJVCB2NhzXm2SsPJ9jJMbkOnACjfNgCIE/UEzuilOUrThDjEz+4HzUyphXyZNSAipBxOBD1igEcA7A1LPaDyR24ytUOXXfpsmGyX8C1Lxnf5Iozo35gx4rfPvDwmNgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=tYHv7XLY6wVXKZAxM24p/i6Bmgoc+Sz3OmypXlexF+qXNKRWGf4xsf7+bDrm1PLynas03V8/S/CLPEuxUV0PXm7uI0T+uWSXBqWpDfNtGZ4Cl3LQlWr4SMBOhHApXiZLOVxWLh4kMYUymjUXacmlRwfwcLrmGOR5uOSdsd/1XNY= Received: by 10.142.128.6 with SMTP id a6mr3243757wfd.1197314627699; Mon, 10 Dec 2007 11:23:47 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 10 Dec 2007 11:23:47 -0800 (PST) Message-ID: <20d2bdfb0712101123v29a37131vf298f06093c8e010@mail.gmail.com> Date: Mon, 10 Dec 2007 14:23:47 -0500 From: "Bruce Lowekamp" To: "Roy, Radhika R Dr CTR USA USAMC" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> X-Google-Sender-Auth: beaf15be0b20a1ad X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Radhika, I think this is something along the lines of what I was thinking. Even if we do decide that option 3/your c is necessary, I am still hoping it will not be mandatory to implement, because I would like to avoid the cost when it's not needed. I think the question of when a SIP device would want to extend SIP and when it implement functionality using get/put in a client protocol is interesting. You're right that we're not chartered to extend SIP, but my understanding is that the p2psip wg can refer proposals to sipping. My understanding is that if we decide we need event packages on the lines of draft-li-p2psip-client-protocol-00, then that item would be taken up by sipping. Bruce On Dec 5, 2007 2:34 PM, Roy, Radhika R Dr CTR USA USAMC wrote: > Bruce: > > I like your suggestion for P2PSIP Client protocol. Let me add a little as follows: > > a. Let your option (1) be the choice. > b. Let additional methods like GET/STORE. > c. Let it could have storage and other properties. > > Items (b) and (c) may be added as a set of separate properties in the name of protocol/feature/capabilities and we may not call them SIP. Because any extensions of SIP for items b and c will NOT have the properties of the SIP protocol for which SIP has been charted. Moreover, we not charted to extend SIP. > > The combination items a, b, and c will make a P2P Client (i.e. SIP UA + P2PSIP Client UA) and the combined protocol may be termed as P2PSIP Client protocol. > > How about this? > > Best regards, > Radhika > > > ----- Original Message ----- > From: Bruce Lowekamp > Date: Wednesday, December 5, 2007 14:17 > Subject: [P2PSIP] client protocol architectural issues > To: P2PSIP Mailing List > > > There has been tons of discussions on the issue of "do we need a > > client protocol?" or "why do we need a client protocol?" We have the > > topic again on the agenda this afternoon. > > > > > > I want to make two assertions: > > - we need a client protocol. There's just a lot of disagreement on > > what it looks like. > > - most of the peer protocol proposals have a way of integrating > > clients at the p2p layer. there is some question as to what > > capabilities are needed at this layer. > > > > > > > > The major controversy seems to be over architecture. Three > > options include: > > 1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP > > devices. Primary communication between a client and peer will be > > using the peer as its default outbound proxy, with any SIP extensions > > handled at the SIP layer, as in draft-li-p2psip-client-protocol. > > 2) P2PSIP peers are not necessarily SIP devices. P2PSIP clients are > > SIP devices and may need to interact with a peer using P2P protocol > > GET/STORE operations. > > 3) P2PSIP peers and clients are not necessarily either SIP > > devices. A > > client may try to participate in the overlay by contributing storage > > to help peers or other functions generally associated with overlay > > peers without actually participating in all of the peer functionality. > > > > > > > > My personal belief is that the primary P2PSIP architecture should > > be (1). > > > > I think there are justifications for architecture (2), and I think > > that most/all of the protocol proposals support this. > > > > I am concerned about (3). I know that many real P2P deployments > > support this type of behavior. In one sentence, my understanding is > > that that primary motivation for these deployments is a way of making > > use of devices behind NATs. I think we (p2psip) have been looking at > > different (and more complicated) NAT traversal solutions > > (ICE/tunneling) because we believe many of our application scenarios > > don't have the same global deployment features, and we are aiming at > > topologies where most of our peers are behind NATs. (unlike > > topologies where most devices are in college dorms) > > > > Supporting (3) significantly complicates the protocol (in other > > directions than it is already complicated by other requirements such > > as NAT traversal). One of my reasons for being unsure whether we need > > it is that for P2PSIP, there are already SIP-level ways of providing > > services to the overlay. In a lot of senses, merely registering an > > AoR to peerid/ip mapping is providing services, because one of the > > fundamental roles of a SIP device is to provide SIP services. For the > > P2PSIP case, other than resource storage, what are these services that > > don't fit within the SIP model? For applications other than SIP, what > > are these services? Wouldn't any other application have its own > > application-level way of offering services? > > > > If there is consensus that it is important for the peer protocol to > > support peer/client interaction that allows the clients to provide > > storage (and maybe other peer-level functionality), I'm OK with that > > as long as it is optional and ideally not in the core draft, something > > like draft-zheng-p2psip-client-protocol. > > > > If the need for a "client protocol" for devices that provides > > "services" requires a different architecture, I'm very curious what > > they are and specific reasons why they exist and are not either > > providing SIP services or merely needing to do GET/STORE with the > > overlay to register their presence. > > > > Bruce > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 14:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oIs-0006m6-DO; Mon, 10 Dec 2007 14:28:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oIq-0006d4-8o for p2psip@ietf.org; Mon, 10 Dec 2007 14:28:32 -0500 Received: from nz-out-0506.google.com ([64.233.162.231]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1oIo-0005Rg-Oc for p2psip@ietf.org; Mon, 10 Dec 2007 14:28:32 -0500 Received: by nz-out-0506.google.com with SMTP id n1so641439nzf for ; Mon, 10 Dec 2007 11:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=DsEYicsPgdN16fs2mpDgUDs4vLx+JhsAG2B5qusBU5c=; b=OdUB6tdIXd0AmmDUTLMzfdZpe7OKV2oECw4Gbd5AygcvVDyFjRfURxB4yLYPQKfT6U10+YgB3E0mLtqozBlKWKffrobm+AIvq1uH09cU8HZDwrMvwei3z8iM3xz9HSHq70Qz+Rng6Y7eX4fcLzsmeJ5ybq5J162FHPzyWs44QxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=U4bOaqLmBDBhLUh0gCys3OM8YmD3EMuecReQdvAer7DSpp7Kqmmb0uSrXVDBwPNRdRSgbit9DWI93GdvZ5yGVsh6AXbNU4grPoaNz4wPeEOA253FDto4rp46AYwqh2U2iK8kVyWXE/2WoAaaVs4nAApAM0qcsOvcLTWbV/4IA/E= Received: by 10.142.140.14 with SMTP id n14mr3233220wfd.1197314304359; Mon, 10 Dec 2007 11:18:24 -0800 (PST) Received: by 10.142.132.18 with HTTP; Mon, 10 Dec 2007 11:18:24 -0800 (PST) Message-ID: <20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com> Date: Mon, 10 Dec 2007 14:18:24 -0500 From: "Bruce Lowekamp" To: "Eunsoo Shim" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> <7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com> X-Google-Sender-Auth: 72e059e9e436cab7 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eunsoo, I'm sorry, I will try to be more clear. My initial statement was that there are a range of architectural options, which I listed as: - option 1: the only p2psip clients are sip devices that speak sip with p2psip peers - option 2: there is a get/put client protocol that allows non-sip interaction between clients and peers - option 3: there is a more complicated client protocol that allows "clients" to offer storage or other services to the peers The statement I made after that in my initial email was: > My personal belief is that the primary P2PSIP architecture should be (1). I still support this, for a few reasons. First, observe that I made that statement about P2P*SIP* (emphasis added). It's SIP. Discussion of non-SIP is further down. In a P2P*SIP* architecture, it seems reasonable to assume that many if not most of the devices will be SIP devices. For compatibility with existing SIP devices (which cannot possibly be peers), they will need a SIP proxy for connectivity, which will most probably be a P2PSIP device. So that's SIP being used as a "client" protocol. Most devices that can speak the peer protocol, I will assume will be peers. There are some arguments for why a P2PSIP device can't be a peer, as your draft points out, and for almost all of those scenarios, SIP will work fine. Now, there are a few deployment scenarios for P2PSIP where for some reason the clients can't use a P2PSIP peer as their proxy. Your draft listed some, and I think there are others. In those cases, I think option 2 is necessary. I think it's necessary, it's just that the default should be option 1. I should add that I am assuming that if we choose to support option 2, p2psip implementations are still free to support option 1, it's just that the peer protocol is required to support option 2 (client get/put). Now, for non-SIP, well, the quick answer is that we're not chartered to work on non-SIP. So that's not a question about P2P*SIP*. But the longer answer is that I suspect most non-SIP applications will already have their own protocol, and I still believe that the vast majority of deployment scenarios should require no more than option 2 (although there are obviously important applications of option 3 as well). Bruce On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > I don't quite understand how what you wrote below is connected to your > initial proposal that P2PSIP architecture should require all > devices/nodes (Peers and Clients) to be coupled with SIP entities. > Could you explain again the reason of your proposal? > Thanks. > > Eunsoo > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp wrote: > > On Dec 6, 2007 10:28 AM, Eunsoo Shim wrote: > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp wrote: > > > > For P2PSIP, one option for "clients" is essentially for the peer to be > > > > acting as a proxy for clients that speak only SIP and be totally > > > > unaware of the overlay. > > > > > > Other protocols will likely have their own > > > > way of using the peer as a client without being aware of the overlay. > > > > > > > > > > This is a problem with removing the concept of Clients in the overlay layer. > > > If there is the Client node type, application protocols don't need to > > > have their own way to support client-like devices. > > > > > > > My point is very simple. Most applications that have been discussed > > already exist before a p2p version has been created. So they already > > have this protocol. > > > > > > > > > > > > 2 says that whatever the application is, the application will be able > > > > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > 3 says that there is some need for these nodes to interact at a more > > > > > > basic, non-application way, that is not simply doing location for that > > > > > > application. It has nothing to do with non-SIP, it means that > > > > > > whatever the application is, it's non-application. > > > > > > > > > > > I don't understand this either. > > > > > > > > 2 is clients use the overlay's get/put. So they know the overlay > > > > exists and speak the p2p protocol, but don't provide storage to the > > > > overlay, they just use it to resolve lookups. > > > > > > > > 3 says that the clients will need to do more than just simple get/put. > > > > Trying to contribute storage to the peer would be the most obvious > > > > example of this. > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the overlay > > > layer may or may not be coupled with SIP entities. What you are > > > talking about is whether the Clients will do in the overlay layer more > > > than just using the overlay with GET/PUT. > > > > Exactly. SIP (since it's what we're chartered for) is just the > > primary working example of an application. > > > > Bruce > > > > > > -- > Eunsoo > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 10 20:25:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tsh-0006AX-Fj; Mon, 10 Dec 2007 20:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tsg-0006AN-7C for p2psip@ietf.org; Mon, 10 Dec 2007 20:25:54 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1tse-0002A4-UQ for p2psip@ietf.org; Mon, 10 Dec 2007 20:25:54 -0500 Received: by nz-out-0506.google.com with SMTP id n1so751577nzf for ; Mon, 10 Dec 2007 17:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=1kMrPxLCUzUzoa9eHV8kXLGF7XeuaP2BlILFY3NZBW8=; b=cs3H1w3qOi4WbC9zNuePyXCOcq4Knjald1Zx4uyoKTu3VWnO9if97981Q07F9pp868S6RC9zgqz5Yshoc0TlawuYo6RBpp49iK4BHksHwb1o+jUlabg/hDRqobISpCoOyi9UYwZK/udkiK9MlrRP6k1P9enF4EfgTsrBHRyR0w8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=U7+oM8Z5LzkFxe+nPH7u1TTV75mzVRGrFJGviokXe7GA/4WZxcg2bFNE+J65tAFN3Cn0iiPDeF+Q8vGPiun2f9w6WnMMa/YVzu0B7Wf8wDHhKyj1SuewoRhHL0ctvD7XySio0bQPcJ9A/trFS3uWpsPGKa8afm69XUQlvePMMas= Received: by 10.142.232.20 with SMTP id e20mr1926190wfh.1197336351611; Mon, 10 Dec 2007 17:25:51 -0800 (PST) Received: by 10.142.200.16 with HTTP; Mon, 10 Dec 2007 17:25:51 -0800 (PST) Message-ID: <7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> Date: Tue, 11 Dec 2007 09:25:51 +0800 From: "lichun li" To: "Bruce Lowekamp" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com> MIME-Version: 1.0 References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com> <20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com> <7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> <7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com> <20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1711145399==" Errors-To: p2psip-bounces@ietf.org --===============1711145399== Content-Type: multipart/alternative; boundary="----=_Part_23149_11765663.1197336351619" ------=_Part_23149_11765663.1197336351619 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I also think option 1 and 2 are necessary. Maybe only one type of node is called as "client" eventually. But there should be more than one type of node in P2PSIP other than peer. On Dec 11, 2007 3:18 AM, Bruce Lowekamp wrote: > Eunsoo, > > I'm sorry, I will try to be more clear. > > My initial statement was that there are a range of architectural > options, which I listed as: > - option 1: the only p2psip clients are sip devices that speak sip > with p2psip peers > - option 2: there is a get/put client protocol that allows non-sip > interaction between clients and peers > - option 3: there is a more complicated client protocol that allows > "clients" to offer storage or other services to the peers > > > The statement I made after that in my initial email was: > > My personal belief is that the primary P2PSIP architecture should be > (1). > > I still support this, for a few reasons. First, observe that I made > that statement about P2P*SIP* (emphasis added). It's SIP. Discussion > of non-SIP is further down. In a P2P*SIP* architecture, it seems > reasonable to assume that many if not most of the devices will be SIP > devices. For compatibility with existing SIP devices (which cannot > possibly be peers), they will need a SIP proxy for connectivity, which > will most probably be a P2PSIP device. So that's SIP being used as a > "client" protocol. Most devices that can speak the peer protocol, I > will assume will be peers. There are some arguments for why a P2PSIP > device can't be a peer, as your draft points out, and for almost all > of those scenarios, SIP will work fine. > > Now, there are a few deployment scenarios for P2PSIP where for some > reason the clients can't use a P2PSIP peer as their proxy. Your draft > listed some, and I think there are others. In those cases, I think > option 2 is necessary. I think it's necessary, it's just that the > default should be option 1. > > I should add that I am assuming that if we choose to support option 2, > p2psip implementations are still free to support option 1, it's just > that the peer protocol is required to support option 2 (client > get/put). > > Now, for non-SIP, well, the quick answer is that we're not chartered > to work on non-SIP. So that's not a question about P2P*SIP*. But the > longer answer is that I suspect most non-SIP applications will already > have their own protocol, and I still believe that the vast majority of > deployment scenarios should require no more than option 2 (although > there are obviously important applications of option 3 as well). > > Bruce > > > On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > > I don't quite understand how what you wrote below is connected to your > > initial proposal that P2PSIP architecture should require all > > devices/nodes (Peers and Clients) to be coupled with SIP entities. > > Could you explain again the reason of your proposal? > > Thanks. > > > > Eunsoo > > > > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp wrote: > > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp > wrote: > > > > > For P2PSIP, one option for "clients" is essentially for the peer > to be > > > > > acting as a proxy for clients that speak only SIP and be totally > > > > > unaware of the overlay. > > > > > > > > Other protocols will likely have their own > > > > > way of using the peer as a client without being aware of the > overlay. > > > > > > > > > > > > > This is a problem with removing the concept of Clients in the > overlay layer. > > > > If there is the Client node type, application protocols don't need > to > > > > have their own way to support client-like devices. > > > > > > > > > > My point is very simple. Most applications that have been discussed > > > already exist before a p2p version has been created. So they already > > > have this protocol. > > > > > > > > > > > > > > > 2 says that whatever the application is, the application will > be able > > > > > > > to use GET/STORE to provide provides the lookup and > CONNECT/TUNNEL > > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > > > 3 says that there is some need for these nodes to interact at > a more > > > > > > > basic, non-application way, that is not simply doing location > for that > > > > > > > application. It has nothing to do with non-SIP, it means that > > > > > > > whatever the application is, it's non-application. > > > > > > > > > > > > > I don't understand this either. > > > > > > > > > > 2 is clients use the overlay's get/put. So they know the overlay > > > > > exists and speak the p2p protocol, but don't provide storage to > the > > > > > overlay, they just use it to resolve lookups. > > > > > > > > > > 3 says that the clients will need to do more than just simple > get/put. > > > > > Trying to contribute storage to the peer would be the most > obvious > > > > > example of this. > > > > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the > overlay > > > > layer may or may not be coupled with SIP entities. What you are > > > > talking about is whether the Clients will do in the overlay layer > more > > > > than just using the overlay with GET/PUT. > > > > > > Exactly. SIP (since it's what we're chartered for) is just the > > > primary working example of an application. > > > > > > Bruce > > > > > > > > > > > -- > > Eunsoo > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_23149_11765663.1197336351619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I also think option 1 and 2 are necessary. Maybe only one type of node is called as "client" eventually. But there should be more than one type of node in P2PSIP other than peer.

 
On Dec 11, 2007 3:18 AM, Bruce Lowekamp <lowekamp@sipeerior.com> wrote:
Eunsoo,

I'm sorry, I will try to be more clear.

My initial statement was that there are a range of architectural
options, which I listed as:
- option 1: the only p2psip clients are sip devices that speak sip
with p2psip peers
- option 2: there is a get/put client protocol that allows non-sip
interaction between clients and peers
- option 3: there is a more complicated client protocol that allows
"clients" to offer storage or other services to the peers


The statement I made after that in my initial email was:
> My personal belief is that the primary P2PSIP architecture should be (1).

I still support this, for a few reasons.  First, observe that I made
that statement about P2P*SIP* (emphasis added).  It's SIP.  Discussion
of non-SIP is further down.  In a P2P*SIP* architecture, it seems
reasonable to assume that many if not most of the devices will be SIP
devices.  For compatibility with existing SIP devices (which cannot
possibly be peers), they will need a SIP proxy for connectivity, which
will most probably be a P2PSIP device.  So that's SIP being used as a
"client" protocol.  Most devices that can speak the peer protocol, I
will assume will be peers.  There are some arguments for why a P2PSIP
device can't be a peer, as your draft points out, and for almost all
of those scenarios, SIP will work fine.

Now, there are a few deployment scenarios for P2PSIP where for some
reason the clients can't use a P2PSIP peer as their proxy.  Your draft
listed some, and I think there are others.  In those cases, I think
option 2 is necessary.  I think it's necessary, it's just that the
default should be option 1.

I should add that I am assuming that if we choose to support option 2,
p2psip implementations are still free to support option 1, it's just
that the peer protocol is required to support option 2 (client
get/put).

Now, for non-SIP, well, the quick answer is that we're not chartered
to work on non-SIP.  So that's not a question about P2P*SIP*.  But the
longer answer is that I suspect most non-SIP applications will already
have their own protocol, and I still believe that the vast majority of
deployment scenarios should require no more than option 2 (although
there are obviously important applications of option 3 as well).

Bruce


On Dec 7, 2007 11:38 AM, Eunsoo Shim <eunsooshim@gmail.com> wrote:
> I don't quite understand how what you wrote below is connected to your
> initial proposal that P2PSIP architecture should require all
> devices/nodes (Peers and Clients) to be coupled with SIP entities.
> Could you explain again the reason of your proposal?
> Thanks.
>
> Eunsoo
>
>
> On Dec 6, 2007 2:00 PM, Bruce Lowekamp <lowekamp@sipeerior.com> wrote:
> > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp <lowekamp@sipeerior.com > wrote:
> > > > For P2PSIP, one option for "clients" is essentially for the peer to be
> > > > acting as a proxy for clients that speak only SIP and be totally
> > > > unaware of the overlay.
> > >
> > >  Other protocols will likely have their own
> > > > way of using the peer as a client without being aware of the overlay.
> > > >
> > >
> > > This is a problem with removing the concept of Clients in the overlay layer.
> > > If there is the Client node type, application protocols don't need to
> > > have their own way to support  client-like devices.
> > >
> >
> > My point is very simple.  Most applications that have been discussed
> > already exist before a p2p version has been created.  So they already
> > have this protocol.
> >
> > > >
> > > > > > 2 says that whatever the application is, the application will be able
> > > > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL
> > > > > > provide connectivity if the target is behind a NAT.
> > > > > >
> > > > > > 3 says that there is some need for these nodes to interact at a more
> > > > > > basic, non-application way, that is not simply doing location for that
> > > > > > application.  It has nothing to do with non-SIP, it means that
> > > > > > whatever the application is, it's non-application.
> > > > > >
> > > > > I don't understand this either.
> > > >
> > > > 2 is clients use the overlay's get/put.  So they know the overlay
> > > > exists and speak the p2p protocol, but don't provide storage to the
> > > > overlay, they just use it to resolve lookups.
> > > >
> > > > 3 says that the clients will need to do more than just simple get/put.
> > > >  Trying to contribute storage to the peer would be the most obvious
> > > > example of this.
> > > >
> > >
> > > (2) and (3) have nothing to do with whether some nodes in the overlay
> > > layer may or may not be coupled with SIP entities. What you are
> > > talking about is whether the Clients will do in the overlay layer more
> > > than just using the overlay with GET/PUT.
> >
> > Exactly.  SIP (since it's what we're chartered for) is just the
> > primary working example of an application.
> >
> > Bruce
> >
>
>
>
> --
> Eunsoo
>
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_23149_11765663.1197336351619-- --===============1711145399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1711145399==-- From p2psip-bounces@ietf.org Tue Dec 11 00:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1xDl-00089X-Ts; Mon, 10 Dec 2007 23:59:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1xDk-00089R-Eu for p2psip@ietf.org; Mon, 10 Dec 2007 23:59:52 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1xDi-0006Cg-Ij for p2psip@ietf.org; Mon, 10 Dec 2007 23:59:52 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J1xDe-0005Eh-3t; Tue, 11 Dec 2007 05:59:49 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1J1xDa-0004KI-NV; Tue, 11 Dec 2007 05:59:45 +0100 Received: from wooky.tm.uka.de (unknown [24.82.128.196]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C12782FC00C; Tue, 11 Dec 2007 05:59:41 +0100 (CET) Message-ID: <475E193C.5010908@tm.uka.de> Date: Mon, 10 Dec 2007 20:59:40 -0800 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] Two-Stage Name Resolution References: <47583A37.6020608@tm.uka.de> <20d2bdfb0712061116x74464efdg3c7de530aaea8c48@mail.gmail.com> <47598626.5090301@tm.uka.de> <20d2bdfb0712101043qbd83a4dvc03e62249f7227f0@mail.gmail.com> In-Reply-To: <20d2bdfb0712101043qbd83a4dvc03e62249f7227f0@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Our implementation currently uses only STUN for NAT traversal. If we add ICE support, we probably would also use a set of candidate addresses instead of a single transport address on KBR layer. For the two-stage name resolution this makes no difference - the second stage simply returns the transport address(es) used in the KBR routing table. Regards, Ingmar Bruce Lowekamp wrote: > How does P2PNS implement the KBR in the presence of NATs? Using HITs > as NodeID has the obvious attraction that there is no mapping to an > IP, but in other cases, there isn't a mapping to a single IP, thus > the proposals for tunneling over the overlay or establishing a direct > connection to a remote peer (identified by peerid) by using ICE. > reload-01 and p2pp both propose using a set of (ice candidate) > addresses but in all cases, fallback to full ice is required when > those don't work. > > Bruce > > > On Dec 7, 2007 12:43 PM, Ingmar Baumgart wrote: >> This is a good point. I think the two-stage approach is only a >> optimization for some use cases. The peer protocol should support all >> the different type of mappings you mentioned on DHT layer. In case this >> is an (AoR, NodeID) mapping you simply go for the second stage on KBR layer. >> >> Regards, >> Ingmar >> >> >> Bruce Lowekamp wrote: >>> I'm concerned about any proposal that restricts resolution to >>> ultimately be a mapping of AoR to IP address. (technically the Common >>> API paper says transport address, of which it says IP is only an >>> example.) There are examples of URI->URI mapping, URI->PeerID (where >>> peerid is the final result because there is not direct IP >>> connectivity), and other combinations with small or large resources >>> being returned. reload-02 uses the term "seed" to indicate that the >>> initial item is not necessarily an AoR or even a URI. >>> >>> I haven't fully digested all the implications in p2pns, but I'm >>> concerned that it appears to restrict the range of mappings that are >>> available. >>> >>> Bruce >>> >>> >>> On Dec 6, 2007 10:06 AM, Ingmar Baumgart wrote: >>>> The P2PNS draft proposes to use a two stage approach to resolve AoRs to >>>> IP addresses. >>>> >>>> 1. Resolve AoR -> NodeID (DHT layer) >>>> 2. Resolve NodeID -> IP (KBR layer) >>>> >>>> This is motivated by some locator/ID split architectures. >>>> The nodeID is used as location independent identifier which is >>>> efficiently resolved to the current location (IP address) by the KBR >>>> layer. The benefit of this design is a mostly static (AoR, NodeID) >>>> binding in the DHT. This could be important if IP address often change >>>> and modification of DHT records is expensive due to security mechanisms >>>> (replication and majority votes). >>>> >>>> Probably it depends on the application scenario which of the two >>>> alternatives (direct storage in a DHT or two-stage stage with KBR/DHT) >>>> performs better. >>>> >>>> In my opinion we should at least try to keep the peer protocol flexible >>>> enough to support both alternatives. >>>> >>>> Any comments? >>>> >>>> Regards, >>>> Ingmar >>>> >>>> -- >>>> Dipl.-Inform. Ingmar Baumgart >>>> Institut für Telematik, Universität Karlsruhe (TH) >>>> Zirkel 2, 76128 Karlsruhe, Germany >>>> Phone: +49 721 608 8281, Fax: +49 721 608 6789 >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>>> >> -- >> >> Dipl.-Inform. Ingmar Baumgart >> Institut für Telematik, Universität Karlsruhe (TH) >> Zirkel 2, 76128 Karlsruhe, Germany >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 >> >> -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 11 07:35:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J24KJ-0001BZ-2i; Tue, 11 Dec 2007 07:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J24KI-0001BU-0e for p2psip@ietf.org; Tue, 11 Dec 2007 07:35:06 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J24KF-0007HJ-AK for p2psip@ietf.org; Tue, 11 Dec 2007 07:35:05 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id D07FEA73DA; Tue, 11 Dec 2007 20:34:57 +0800 (CST) Message-ID: <000c01c83bf2$3aa1dd30$da07740a@dellwei> From: "Wei Gengyu" To: "Bruce Lowekamp" References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Tue, 11 Dec 2007 20:34:44 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1452501139==" Errors-To: p2psip-bounces@ietf.org --===============1452501139== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgQnJ1Y2UsIA0KDQpJIHRoaW5rIHRoZXJlIGFyZSBzb21lIHByb2JsZW1zIHRvIGJlIGNsYXJp ZmllZCBhZnRlciByZWFkaW5nIHlvdXIgZW1haWwuIA0KDQpXaGVuIHlvdSBzdXBwb3NlIHRoYXQg UDJQU0lQIG92ZXJsYXkgd29ya3MgaW4gYW4gZW52aXJvbm1lbnQgd2l0aG91dCBwcm92aXNpb25l ZCBETlMgc3VwcG9ydCBmb3IgdGhlIG92ZXJsYXksIA0KeW91IGFsc28gc3VwcG9zZSB0aGVyZSBh cmUgbm90IG90aGVyIGZhY2lsaXRpZXMsIHN1Y2ggYXMgUDJQTlMsIHRvIHN1cHBvcnQgZm9yIG1h cHBpbmcgaG9zdCBpZCB0byBJUCBhZGRyZXNzLg0KU28geW91IGNvbmNsdWRlIHRoYXQgeW91IG5l ZWQgdG8gZG8gbWFwcGluZyBhdCB0aGUgUDJQU0lQIG92ZXJsYXkuICBJbiB0aGlzIHNpdHVhdGlv biBISVAgaXMgcmVxdWlyZWQuDQpEbyBJIHVuZGVyc3RhbmQgaXQgcmlnaHQ/DQoNCkkgYWxzbyBh ZG1pdCB0aGF0IEhJUCBpcyBnb29kIGluIHRlcm1zIG9mIHN1cHBvcnRpbmcgbW9iaWxpdHksIG11 bHRpaG9tZSwgdW5pcXVlIGhvc3QgaWQgZXRjLg0KQnV0LCBJIHRoaW5rIHdlIHJlYWx5IG5lZWQg dG8gbWFrZSB0aGUgd29ya2luZyBlbnZpcm9ubWVudCBvZiAgUDJQU0lQIG92ZXJsYXkgY2xlYXIu DQoNCkZvciBjb252ZW50aW9uYWwgSW50ZXJuZXQgd2l0aCBETlMsIFAyUFNJUCBvdmVybGF5IGNv dWxkIGdldCB0aGUgSVAgYWRkcmVzcyBieSBtYXBwaW5nIEROUyB0byBJUCBhZGRyZXNzLg0KRm9y IHRoZSBJbnRlcm5ldCB3aXRoIEhJUCBhdCBiZXR3ZWVuIG5ldHdvcmsgbGF5ZXIgYW5kIHRyYW5z cG9ydCBsYXllciBhbmQgRE5TIGFsc28gd29ya3MsDQogICAgICBQMlBTSVAgb3ZlcmxheSBjb3Vs ZCAgZ2V0IHRoZSBJUCBhZGRyZXNzIGJ5IG1hcHBpbmcgRE5TLUhJVC1JUCBhZGRyZXNzLg0KRm9y IHRoZSB3b3JraW5nIGVudmlyb25tZW50IHdpdGhvdXQgRE5TLCBwcm9iYWJseSBhbm90aGVyIG1h cHBpbmcgbWVjaGFuaXNtLCBzdWNoIGFzIFAyUE5TLCB3b3VsZCB3b3JrLg0KDQpTbyB3aGF0IHlv dSBzdXBwb3NlZCBzZWVtcyB0byBiZSB0aGUgd29ya2luZyBlbnZpcm9ubWVudCB3aXRob3V0IERO Uywgd2l0aG91dCBISVAgYXQgbmV0d29yayBsYXllci4NCklzIGl0IGluIHRoaXMgc2l0dWF0aW9u IHRoYXQgSElQIHdvdWxkIHdvcmsgYXQgdGhlIFAyUFNJUCBvdmVybGF5PyANCg0KSSBhZ3JlZSB3 aGF0IHlvdSBzYWlkICJ3ZSBuZWVkIHRvIGJlIGNsZWFyIG9uIGhvdyB0aGUgbGF5ZXJpbmcgd29y a3MgYW5kDQp3aGF0IHN1cHBvcnQgaXMgbmVlZGVkIGluIGJvdGggZGlyZWN0aW9ucyBiZWZvcmUg ZGVjaWRpbmcgaG93IHRvIGFjY29tcGxpc2ggaXQuIg0KDQpSZWdhcmRzLA0KDQpHZW5neXUNCg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJCcnVjZSBMb3dla2FtcCIgPGxv d2VrYW1wQHNpcGVlcmlvci5jb20+DQpUbzogIk1paWthIEtvbXUiIDxtaWlrYUBpa2kuZmk+DQpD YzogPHAycHNpcEBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDExLCAyMDA3IDEy OjU2IEFNDQpTdWJqZWN0OiBSZTogW1AyUFNJUF0gUmU6IEhJUCBwcm9zIGFuZCBjb25zDQoNCg0K PiANCj4gKEkgcmVhcnJhbmdlZCB0aGlzIGEgbGl0dGxlIGJpdCB0byBicmluZyB0aGVzZSB0d28g aXNzdWVzIHRvZ2V0aGVyLikNCj4gDQo+IE9uZSBvZiB0aGUgY29uZnVzaW5nIHRoaW5ncyBhYm91 dCBhcHBseWluZyBISVAgdG8gcDJwc2lwIGlzIHRoZQ0KPiBsYXllcmluZyBpc3N1ZXMgcmVxdWly ZWQgdG8gYWRkcmVzcyB0aGUgZGVwbG95bWVudCBzY2VuYXJpb3MgZm9yDQo+IHAycHNpcC4gIFdl IG5lZWQgaXQgdG8gd29yayBpbiBhbiBlbnZpcm9ubWVudCB3aXRob3V0IHByb3Zpc2lvbmVkIERO Uw0KPiBzdXBwb3J0IGZvciB0aGUgb3ZlcmxheSBhbmQgd2hlcmUgd2UgY2Fubm90IGFzc3VtZSBh biBpbmZyYXN0cnVjdHVyZQ0KPiBwcm92aWRlciBwcm92aWRpbmcgSElQIHJlbGF5cy4gIFdlIG5l ZWQgdG8gYmUgYWJsZSB0byBvYnRhaW4gdGhvc2UNCj4gc2VydmljZXMgZnJvbSBwZWVycyBpbiB0 aGUgb3ZlcmxheS4gIFNvLCBtaW5pbWFsbHksIHRoaXMgbWVhbnMgdGhlDQo+IGFiaWxpdHkgdG8g c3VwcG9ydCB0aGUgSElQIHJlbGF5IGZ1bmN0aW9uYWxpdHkgYXQgdGhlIG92ZXJsYXkgbGF5ZXIu DQo+IFRoaXMgaXMgd2hlcmUgdGhlIHByb3Bvc2FsIGJlY29tZXMgY29uZnVzaW5nLCBiZWNhdXNl IHdoaWxlIEhJUA0KPiBwcm92aWRlcyBhIHZlcnkgbmljZSBhYnN0cmFjdGlvbiBvbiB0b3Agb2Yg d2hpY2ggdG8gYnVpbGQgYSBwMnANCj4gYXBwbGljYXRpb24sIGl0IGFsc28gcmVxdWlyZXMgdGhh dCBwMnAgYXBwbGljYXRpb24gZm9yIGl0cw0KPiBjb25uZWN0aXZpdHkuDQo+IA0KPiBJJ3ZlIHNw ZW50IHNvbWUgdGltZSB3b3JraW5nIHdpdGggUGhpbGlwIG9uIGhvdyB0byBwcm92aWRlIHN1cHBv cnQgZm9yDQo+IEhJUCBpbnNpZGUgb2YgYSBwMnBzaXAgcGVlciBwcm90b2NvbCwgYW5kIEkgdGhp bmsgaXQncyBlbnRpcmVseQ0KPiBkb2FibGUsIGJ1dCBJIHRoaW5rIHdlIG5lZWQgdG8gYmUgY2xl YXIgb24gaG93IHRoZSBsYXllcmluZyB3b3JrcyBhbmQNCj4gd2hhdCBzdXBwb3J0IGlzIG5lZWRl ZCBpbiBib3RoIGRpcmVjdGlvbnMgYmVmb3JlIGRlY2lkaW5nIGhvdyB0bw0KPiBhY2NvbXBsaXNo IGl0Lg0KPiANCj4gQnJ1Y2UNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPg== --===============1452501139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1452501139==-- From p2psip-bounces@ietf.org Tue Dec 11 09:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25k4-0005EZ-IB; Tue, 11 Dec 2007 09:05:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25k2-0004qU-L2 for p2psip@ietf.org; Tue, 11 Dec 2007 09:05:46 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J25k1-0006Ta-Kz for p2psip@ietf.org; Tue, 11 Dec 2007 09:05:46 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1J25ju-0005Jc-Pv; Tue, 11 Dec 2007 08:05:39 -0600 From: "Brian Rosen" To: "'lichun li'" , "'Bruce Lowekamp'" References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com><7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com><20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com><7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com><20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com><7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com><20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com><7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com><20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com> <7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> Subject: RE: [P2PSIP] client protocol architectural issues Date: Tue, 11 Dec 2007 09:05:40 -0500 Message-ID: <058c01c83bfe$eb48d510$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> Thread-Index: Acg7lMSexxg3bA+1T3e/3zOiPgz3kAAaUQ3Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I refer you to the minutes of the IETF70 meeting held last week: "We will have clients that will have to do at least a get-put, all = protocols will have to do that, and we'll not put a lot more meeting time into = that for now" We observed that all of the proposed protocols have such an option = defined. That is #2. We clearly permit #1. At the moment, we're probably not going to want to spend more time on = option #3. If the chosen protocol has more, okay, but I don't want to spend endless cycles debating the merits of proposals for #3. Some list discussion on the subject is always interesting as long as we don't divert too much attention from more central issues. I'd prefer to = see that discussion focused on specifics, rather than generalities, but open discussion is always welcome. Brian ________________________________________ From: lichun li [mailto:lilichun@gmail.com]=20 Sent: Monday, December 10, 2007 8:26 PM To: Bruce Lowekamp Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] client protocol architectural issues I also think option=A01 and 2 are necessary.=A0Maybe only one type of = node is called=A0as "client" eventually. But=A0there should be more than one = type of node in P2PSIP other than peer. =A0 On Dec 11, 2007 3:18 AM, Bruce Lowekamp wrote: Eunsoo, I'm sorry, I will try to be more clear. My initial statement was that there are a range of architectural=20 options, which I listed as: - option 1: the only p2psip clients are sip devices that speak sip with p2psip peers - option 2: there is a get/put client protocol that allows non-sip interaction between clients and peers=20 - option 3: there is a more complicated client protocol that allows "clients" to offer storage or other services to the peers The statement I made after that in my initial email was: > My personal belief is that the primary P2PSIP architecture should be = (1). I still support this, for a few reasons. =A0First, observe that I made that statement about P2P*SIP* (emphasis added). =A0It's SIP. = =A0Discussion=20 of non-SIP is further down. =A0In a P2P*SIP* architecture, it seems reasonable to assume that many if not most of the devices will be SIP devices. =A0For compatibility with existing SIP devices (which cannot possibly be peers), they will need a SIP proxy for connectivity, which=20 will most probably be a P2PSIP device. =A0So that's SIP being used as a "client" protocol. =A0Most devices that can speak the peer protocol, I will assume will be peers. =A0There are some arguments for why a P2PSIP=20 device can't be a peer, as your draft points out, and for almost all of those scenarios, SIP will work fine. Now, there are a few deployment scenarios for P2PSIP where for some reason the clients can't use a P2PSIP peer as their proxy. =A0Your draft = listed some, and I think there are others. =A0In those cases, I think option 2 is necessary. =A0I think it's necessary, it's just that the default should be option 1. I should add that I am assuming that if we choose to support option 2,=20 p2psip implementations are still free to support option 1, it's just that the peer protocol is required to support option 2 (client get/put). Now, for non-SIP, well, the quick answer is that we're not chartered=20 to work on non-SIP. =A0So that's not a question about P2P*SIP*. =A0But = the longer answer is that I suspect most non-SIP applications will already have their own protocol, and I still believe that the vast majority of=20 deployment scenarios should require no more than option 2 (although there are obviously important applications of option 3 as well). Bruce On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > I don't quite understand how what you wrote below is connected to your = > initial proposal that P2PSIP architecture should require all > devices/nodes (Peers and Clients) to be coupled with SIP entities. > Could you explain again the reason of your proposal? > Thanks.=20 > > Eunsoo > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp wrote: > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp wrote: > > > > For P2PSIP, one option for "clients" is essentially for the peer = to be=20 > > > > acting as a proxy for clients that speak only SIP and be totally > > > > unaware of the overlay.=20 > > > > > > =A0Other protocols will likely have their own > > > > way of using the peer as a client without being aware of the overlay.=20 > > > > > > > > > > This is a problem with removing the concept of Clients in the = overlay layer.=20 > > > If there is the Client node type, application protocols don't need = to=20 > > > have their own way to support =A0client-like devices. > > > > > > > My point is very simple. =A0Most applications that have been = discussed=20 > > already exist before a p2p version has been created. =A0So they = already=20 > > have this protocol. > > > > > > > > > > > > 2 says that whatever the application is, the application = will be able=20 > > > > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL=20 > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > 3 says that there is some need for these nodes to interact = at a more > > > > > > basic, non-application way, that is not simply doing = location for that > > > > > > application. =A0It has nothing to do with non-SIP, it means = that=20 > > > > > > whatever the application is, it's non-application.=20 > > > > > > > > > > > I don't understand this either. > > > > > > > > 2 is clients use the overlay's get/put. =A0So they know the = overlay=20 > > > > exists and speak the p2p protocol, but don't provide storage to = the=20 > > > > overlay, they just use it to resolve lookups. > > > > > > > > 3 says that the clients will need to do more than just simple get/put.=20 > > > > =A0Trying to contribute storage to the peer would be the most = obvious=20 > > > > example of this. > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the = overlay=20 > > > layer may or may not be coupled with SIP entities. What you are=20 > > > talking about is whether the Clients will do in the overlay layer = more > > > than just using the overlay with GET/PUT.=20 > > > > Exactly. =A0SIP (since it's what we're chartered for) is just the=20 > > primary working example of an application. > > > > Bruce > > > > >=20 > -- > Eunsoo > > _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 11 09:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26I6-0002PD-Ro; Tue, 11 Dec 2007 09:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26I5-0002P7-LF for p2psip@ietf.org; Tue, 11 Dec 2007 09:40:57 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J26I3-0001bQ-To for p2psip@ietf.org; Tue, 11 Dec 2007 09:40:57 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSW00A5E3G675@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 11 Dec 2007 06:40:55 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSW007NK3G5CZ@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 11 Dec 2007 06:40:54 -0800 (PST) Date: Tue, 11 Dec 2007 08:40:27 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Meeting minutes posted To: P2PSIP Mailing List Message-id: <0a1301c83c03$c58f4b10$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4d4304a00712061814g25e25d7di999c29a75b7f2da9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Not a correction, but a follow-up... > The link below points to the minutes. Comments/corrections appreciated. > Thanks! > > http://www3.ietf.org/proceedings/07dec/minutes/p2psip.html During the client discussion in Vancouver: "Spencer asked are there peer protocols that won't support clients?" I heard at least a couple of people in Vancouver say "our proposal also accommodates clients", whether it was at the mike or in the hallway. I thought there was at least some response to this question in the room, but that doesn't matter as much ask asking the question on-list, anyway. If you are working on a peer protocol proposal that DOES NOT allow for the possibility of clients, could you say so? What I was trying to get to, was that we need a peer protocol before client support matters at all, so we can focus on peer protocols unless we make design decisions that would exclude clients. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 11 09:58:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26YU-0002KW-AU; Tue, 11 Dec 2007 09:57:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26YS-0002Gl-Bc for p2psip@ietf.org; Tue, 11 Dec 2007 09:57:52 -0500 Received: from exprod6og107.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J26YQ-0001vG-2t for p2psip@ietf.org; Tue, 11 Dec 2007 09:57:52 -0500 Received: from source ([192.150.20.142]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Tue, 11 Dec 2007 06:57:44 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBBEvanT024308; Tue, 11 Dec 2007 06:57:37 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBBEvZRC015828; Tue, 11 Dec 2007 06:57:35 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 06:57:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Tue, 11 Dec 2007 06:57:25 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3D3@namail5.corp.adobe.com> In-Reply-To: <000c01c83bf2$3aa1dd30$da07740a@dellwei> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg78k0N4FXDQqwBT5+cAWYp/T8+kQAE27kg References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <000c01c83bf2$3aa1dd30$da07740a@dellwei> From: "Henry Sinnreich" To: "Wei Gengyu" , "Bruce Lowekamp" X-OriginalArrivalTime: 11 Dec 2007 14:57:35.0337 (UTC) FILETIME=[2A124590:01C83C06] X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Gengyu, Bruce, Diagrams with step by step resolution would be here of help for us. Henry -----Original Message----- From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Tuesday, December 11, 2007 4:35 AM To: Bruce Lowekamp Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons Hi Bruce,=20 I think there are some problems to be clarified after reading your email.=20 When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay,=20 you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address. So you conclude that you need to do mapping at the P2PSIP overlay. In this situation HIP is required. Do I understand it right? I also admit that HIP is good in terms of supporting mobility, multihome, unique host id etc. But, I think we realy need to make the working environment of P2PSIP overlay clear. For conventional Internet with DNS, P2PSIP overlay could get the IP address by mapping DNS to IP address. For the Internet with HIP at between network layer and transport layer and DNS also works, P2PSIP overlay could get the IP address by mapping DNS-HIT-IP address. For the working environment without DNS, probably another mapping mechanism, such as P2PNS, would work. So what you supposed seems to be the working environment without DNS, without HIP at network layer. Is it in this situation that HIP would work at the P2PSIP overlay?=20 I agree what you said "we need to be clear on how the layering works and what support is needed in both directions before deciding how to accomplish it." Regards, Gengyu ----- Original Message -----=20 From: "Bruce Lowekamp" To: "Miika Komu" Cc: Sent: Tuesday, December 11, 2007 12:56 AM Subject: Re: [P2PSIP] Re: HIP pros and cons >=20 > (I rearranged this a little bit to bring these two issues together.) >=20 > One of the confusing things about applying HIP to p2psip is the > layering issues required to address the deployment scenarios for > p2psip. We need it to work in an environment without provisioned DNS > support for the overlay and where we cannot assume an infrastructure > provider providing HIP relays. We need to be able to obtain those > services from peers in the overlay. So, minimally, this means the > ability to support the HIP relay functionality at the overlay layer. > This is where the proposal becomes confusing, because while HIP > provides a very nice abstraction on top of which to build a p2p > application, it also requires that p2p application for its > connectivity. >=20 > I've spent some time working with Philip on how to provide support for > HIP inside of a p2psip peer protocol, and I think it's entirely > doable, but I think we need to be clear on how the layering works and > what support is needed in both directions before deciding how to > accomplish it. >=20 > Bruce >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 11 10:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26yg-0007cr-UD; Tue, 11 Dec 2007 10:24:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J26yf-0007cj-Nc for p2psip@ietf.org; Tue, 11 Dec 2007 10:24:57 -0500 Received: from exprod6og107.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J26yd-0002QG-JX for p2psip@ietf.org; Tue, 11 Dec 2007 10:24:57 -0500 Received: from source ([192.150.20.142]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Tue, 11 Dec 2007 07:24:50 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBBFOlnT028317; Tue, 11 Dec 2007 07:24:48 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBBFObRC020799; Tue, 11 Dec 2007 07:24:37 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 07:24:37 -0800 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 Subject: RE: [P2PSIP] client protocol architectural issues Date: Tue, 11 Dec 2007 07:24:27 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3D4@namail5.corp.adobe.com> In-Reply-To: <058c01c83bfe$eb48d510$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] client protocol architectural issues Thread-Index: Acg7lMSexxg3bA+1T3e/3zOiPgz3kAAaUQ3QAAJ8TyA= References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com><7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com><20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com><7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com><20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com><7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com><20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com><7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com><20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com><7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> <058c01c83bfe$eb48d510$640fa8c0@cis.neustar.com> From: "Henry Sinnreich" To: "Brian Rosen" , "lichun li" , "Bruce Lowekamp" X-OriginalArrivalTime: 11 Dec 2007 15:24:37.0325 (UTC) FILETIME=[F0D9FFD0:01C83C09] X-Spam-Score: -4.0 (----) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I would like to sincerely congratulate the co-chairs for the excellent = handling of the difficult WG meeting. Good job!=20 But alas, nobody is perfect and I feel the client issue was handled in a = heavy handed manner, showing an early manifest bias against clients and = the client protocol. > but I don't want to spend > endless cycles debating the merits of proposals for #3 Option 3 is clearly the most interesting since it is the most powerful. If you put time and company resources into P2P, option 3 is just too = important for "I don't want to spend endless cycles debating" and = probably just have to do it. Since amending the WG charter was mentioned, the other applications, = beyond SIP must also be taken into consideration, such as distributed = directory and range searches as well as other applications that make the = P2PSIP "call" more valuable. My two cents, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, December 11, 2007 6:06 AM To: 'lichun li'; 'Bruce Lowekamp' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] client protocol architectural issues I refer you to the minutes of the IETF70 meeting held last week: "We will have clients that will have to do at least a get-put, all = protocols will have to do that, and we'll not put a lot more meeting time into = that for now" We observed that all of the proposed protocols have such an option = defined. That is #2. We clearly permit #1. At the moment, we're probably not going to want to spend more time on = option #3. If the chosen protocol has more, okay, but I don't want to spend endless cycles debating the merits of proposals for #3. Some list discussion on the subject is always interesting as long as we don't divert too much attention from more central issues. I'd prefer to = see that discussion focused on specifics, rather than generalities, but open discussion is always welcome. Brian ________________________________________ From: lichun li [mailto:lilichun@gmail.com]=20 Sent: Monday, December 10, 2007 8:26 PM To: Bruce Lowekamp Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] client protocol architectural issues I also think option=A01 and 2 are necessary.=A0Maybe only one type of = node is called=A0as "client" eventually. But=A0there should be more than one = type of node in P2PSIP other than peer. =A0 On Dec 11, 2007 3:18 AM, Bruce Lowekamp wrote: Eunsoo, I'm sorry, I will try to be more clear. My initial statement was that there are a range of architectural=20 options, which I listed as: - option 1: the only p2psip clients are sip devices that speak sip with p2psip peers - option 2: there is a get/put client protocol that allows non-sip interaction between clients and peers=20 - option 3: there is a more complicated client protocol that allows "clients" to offer storage or other services to the peers The statement I made after that in my initial email was: > My personal belief is that the primary P2PSIP architecture should be = (1). I still support this, for a few reasons. =A0First, observe that I made that statement about P2P*SIP* (emphasis added). =A0It's SIP. = =A0Discussion=20 of non-SIP is further down. =A0In a P2P*SIP* architecture, it seems reasonable to assume that many if not most of the devices will be SIP devices. =A0For compatibility with existing SIP devices (which cannot possibly be peers), they will need a SIP proxy for connectivity, which=20 will most probably be a P2PSIP device. =A0So that's SIP being used as a "client" protocol. =A0Most devices that can speak the peer protocol, I will assume will be peers. =A0There are some arguments for why a P2PSIP=20 device can't be a peer, as your draft points out, and for almost all of those scenarios, SIP will work fine. Now, there are a few deployment scenarios for P2PSIP where for some reason the clients can't use a P2PSIP peer as their proxy. =A0Your draft = listed some, and I think there are others. =A0In those cases, I think option 2 is necessary. =A0I think it's necessary, it's just that the default should be option 1. I should add that I am assuming that if we choose to support option 2,=20 p2psip implementations are still free to support option 1, it's just that the peer protocol is required to support option 2 (client get/put). Now, for non-SIP, well, the quick answer is that we're not chartered=20 to work on non-SIP. =A0So that's not a question about P2P*SIP*. =A0But = the longer answer is that I suspect most non-SIP applications will already have their own protocol, and I still believe that the vast majority of=20 deployment scenarios should require no more than option 2 (although there are obviously important applications of option 3 as well). Bruce On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > I don't quite understand how what you wrote below is connected to your = > initial proposal that P2PSIP architecture should require all > devices/nodes (Peers and Clients) to be coupled with SIP entities. > Could you explain again the reason of your proposal? > Thanks.=20 > > Eunsoo > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp wrote: > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp wrote: > > > > For P2PSIP, one option for "clients" is essentially for the peer = to be=20 > > > > acting as a proxy for clients that speak only SIP and be totally > > > > unaware of the overlay.=20 > > > > > > =A0Other protocols will likely have their own > > > > way of using the peer as a client without being aware of the overlay.=20 > > > > > > > > > > This is a problem with removing the concept of Clients in the = overlay layer.=20 > > > If there is the Client node type, application protocols don't need = to=20 > > > have their own way to support =A0client-like devices. > > > > > > > My point is very simple. =A0Most applications that have been = discussed=20 > > already exist before a p2p version has been created. =A0So they = already=20 > > have this protocol. > > > > > > > > > > > > 2 says that whatever the application is, the application = will be able=20 > > > > > > to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL=20 > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > 3 says that there is some need for these nodes to interact = at a more > > > > > > basic, non-application way, that is not simply doing = location for that > > > > > > application. =A0It has nothing to do with non-SIP, it means = that=20 > > > > > > whatever the application is, it's non-application.=20 > > > > > > > > > > > I don't understand this either. > > > > > > > > 2 is clients use the overlay's get/put. =A0So they know the = overlay=20 > > > > exists and speak the p2p protocol, but don't provide storage to = the=20 > > > > overlay, they just use it to resolve lookups. > > > > > > > > 3 says that the clients will need to do more than just simple get/put.=20 > > > > =A0Trying to contribute storage to the peer would be the most = obvious=20 > > > > example of this. > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the = overlay=20 > > > layer may or may not be coupled with SIP entities. What you are=20 > > > talking about is whether the Clients will do in the overlay layer = more > > > than just using the overlay with GET/PUT.=20 > > > > Exactly. =A0SIP (since it's what we're chartered for) is just the=20 > > primary working example of an application. > > > > Bruce > > > > >=20 > -- > Eunsoo > > _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 11 10:47:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27Ks-0008Gu-5a; Tue, 11 Dec 2007 10:47:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27Kq-0008Gn-JB for p2psip@ietf.org; Tue, 11 Dec 2007 10:47:52 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J27Kp-0000RQ-HQ for p2psip@ietf.org; Tue, 11 Dec 2007 10:47:52 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1J27Kl-0005Rj-VO; Tue, 11 Dec 2007 09:47:48 -0600 From: "Brian Rosen" To: "'Henry Sinnreich'" , "'lichun li'" , "'Bruce Lowekamp'" References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com><7b683f3f0712051147j174852e8oeabccce384ccf1ab@mail.gmail.com><20d2bdfb0712051258j10963bd1h74a975acb13ed007@mail.gmail.com><7b683f3f0712060702p1866ec7bk46b1faaf238a74fa@mail.gmail.com><20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com><7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com><20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com><7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com><20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com><7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> <058c01c83bfe$eb48d510$640fa8c0@cis.neustar.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3D4@namail5.corp.adobe.com> Subject: RE: [P2PSIP] client protocol architectural issues Date: Tue, 11 Dec 2007 10:47:45 -0500 Message-ID: <05cb01c83c0d$2e5d5890$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3D4@namail5.corp.adobe.com> Thread-Index: Acg7lMSexxg3bA+1T3e/3zOiPgz3kAAaUQ3QAAJ8TyAAASNXkA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry Like most IETF work group, we're subject to scope creep. You are = suggesting scope creep; start working on non-SIP p2p before we have p2psip standardized. You are free to propose a charter change. We'll see what support it = gets. Right now, it's out of scope. It's relevant enough that we'll tolerate = some list discussion, but our scope is p2psip. Brian=20 > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, December 11, 2007 10:24 AM > To: Brian Rosen; lichun li; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] client protocol architectural issues >=20 > I would like to sincerely congratulate the co-chairs for the excellent > handling of the difficult WG meeting. Good job! >=20 > But alas, nobody is perfect and I feel the client issue was handled in = a > heavy handed manner, showing an early manifest bias against clients = and > the client protocol. >=20 > > but I don't want to spend > > endless cycles debating the merits of proposals for #3 >=20 > Option 3 is clearly the most interesting since it is the most = powerful. >=20 > If you put time and company resources into P2P, option 3 is just too > important for "I don't want to spend endless cycles debating" and = probably > just have to do it. >=20 > Since amending the WG charter was mentioned, the other applications, > beyond SIP must also be taken into consideration, such as distributed > directory and range searches as well as other applications that make = the > P2PSIP "call" more valuable. >=20 > My two cents, >=20 > Henry >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, December 11, 2007 6:06 AM > To: 'lichun li'; 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] client protocol architectural issues >=20 > I refer you to the minutes of the IETF70 meeting held last week: > "We will have clients that will have to do at least a get-put, all > protocols > will have to do that, and we'll not put a lot more meeting time into = that > for now" >=20 > We observed that all of the proposed protocols have such an option > defined. > That is #2. We clearly permit #1. >=20 > At the moment, we're probably not going to want to spend more time on > option > #3. If the chosen protocol has more, okay, but I don't want to spend > endless cycles debating the merits of proposals for #3. >=20 > Some list discussion on the subject is always interesting as long as = we > don't divert too much attention from more central issues. I'd prefer = to > see > that discussion focused on specifics, rather than generalities, but = open > discussion is always welcome. >=20 > Brian >=20 >=20 >=20 > ________________________________________ > From: lichun li [mailto:lilichun@gmail.com] > Sent: Monday, December 10, 2007 8:26 PM > To: Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] client protocol architectural issues >=20 > I also think option=A01 and 2 are necessary.=A0Maybe only one type of = node is > called=A0as "client" eventually. But=A0there should be more than one = type of > node in P2PSIP other than peer. >=20 >=20 > On Dec 11, 2007 3:18 AM, Bruce Lowekamp = wrote: > Eunsoo, >=20 > I'm sorry, I will try to be more clear. >=20 > My initial statement was that there are a range of architectural > options, which I listed as: > - option 1: the only p2psip clients are sip devices that speak sip > with p2psip peers > - option 2: there is a get/put client protocol that allows non-sip > interaction between clients and peers > - option 3: there is a more complicated client protocol that allows > "clients" to offer storage or other services to the peers >=20 >=20 > The statement I made after that in my initial email was: > > My personal belief is that the primary P2PSIP architecture should be > (1). > I still support this, for a few reasons. =A0First, observe that I made > that statement about P2P*SIP* (emphasis added). =A0It's SIP. = =A0Discussion > of non-SIP is further down. =A0In a P2P*SIP* architecture, it seems > reasonable to assume that many if not most of the devices will be SIP > devices. =A0For compatibility with existing SIP devices (which cannot > possibly be peers), they will need a SIP proxy for connectivity, which > will most probably be a P2PSIP device. =A0So that's SIP being used as = a > "client" protocol. =A0Most devices that can speak the peer protocol, I > will assume will be peers. =A0There are some arguments for why a = P2PSIP > device can't be a peer, as your draft points out, and for almost all > of those scenarios, SIP will work fine. >=20 > Now, there are a few deployment scenarios for P2PSIP where for some > reason the clients can't use a P2PSIP peer as their proxy. =A0Your = draft > listed some, and I think there are others. =A0In those cases, I think > option 2 is necessary. =A0I think it's necessary, it's just that the > default should be option 1. >=20 > I should add that I am assuming that if we choose to support option 2, > p2psip implementations are still free to support option 1, it's just > that the peer protocol is required to support option 2 (client > get/put). >=20 > Now, for non-SIP, well, the quick answer is that we're not chartered > to work on non-SIP. =A0So that's not a question about P2P*SIP*. =A0But = the > longer answer is that I suspect most non-SIP applications will already > have their own protocol, and I still believe that the vast majority of > deployment scenarios should require no more than option 2 (although > there are obviously important applications of option 3 as well). >=20 > Bruce >=20 >=20 > On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > > I don't quite understand how what you wrote below is connected to = your > > initial proposal that P2PSIP architecture should require all > > devices/nodes (Peers and Clients) to be coupled with SIP entities. > > Could you explain again the reason of your proposal? > > Thanks. > > > > Eunsoo > > > > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp = wrote: > > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> = wrote: > > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp > wrote: > > > > > For P2PSIP, one option for "clients" is essentially for the = peer > to > be > > > > > acting as a proxy for clients that speak only SIP and be = totally > > > > > unaware of the overlay. > > > > > > > > =A0Other protocols will likely have their own > > > > > way of using the peer as a client without being aware of the > overlay. > > > > > > > > > > > > > This is a problem with removing the concept of Clients in the > overlay > layer. > > > > If there is the Client node type, application protocols don't = need > to > > > > have their own way to support =A0client-like devices. > > > > > > > > > > My point is very simple. =A0Most applications that have been = discussed > > > already exist before a p2p version has been created. =A0So they = already > > > have this protocol. > > > > > > > > > > > > > > > 2 says that whatever the application is, the application = will > be > able > > > > > > > to use GET/STORE to provide provides the lookup and > CONNECT/TUNNEL > > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > > > 3 says that there is some need for these nodes to interact = at > a > more > > > > > > > basic, non-application way, that is not simply doing = location > for that > > > > > > > application. =A0It has nothing to do with non-SIP, it = means that > > > > > > > whatever the application is, it's non-application. > > > > > > > > > > > > > I don't understand this either. > > > > > > > > > > 2 is clients use the overlay's get/put. =A0So they know the = overlay > > > > > exists and speak the p2p protocol, but don't provide storage = to > the > > > > > overlay, they just use it to resolve lookups. > > > > > > > > > > 3 says that the clients will need to do more than just simple > get/put. > > > > > =A0Trying to contribute storage to the peer would be the most > obvious > > > > > example of this. > > > > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the > overlay > > > > layer may or may not be coupled with SIP entities. What you are > > > > talking about is whether the Clients will do in the overlay = layer > more > > > > than just using the overlay with GET/PUT. > > > > > > Exactly. =A0SIP (since it's what we're chartered for) is just the > > > primary working example of an application. > > > > > > Bruce > > > > > > > > > > > -- > > Eunsoo > > > > >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 >=20 > -- > Sincerely yours, >=20 > Lichun Li > Mobile Life New Media Lab, BUPT >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 11 19:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Fp9-0000Gq-NW; Tue, 11 Dec 2007 19:51:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Fp8-00009N-Mt for p2psip@ietf.org; Tue, 11 Dec 2007 19:51:42 -0500 Received: from exprod6og101.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Fp7-0007ml-Sy for p2psip@ietf.org; Tue, 11 Dec 2007 19:51:42 -0500 Received: from source ([192.150.20.142]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Tue, 11 Dec 2007 16:51:34 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBC0pNnT022217; Tue, 11 Dec 2007 16:51:23 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBC0pMRC012546; Tue, 11 Dec 2007 16:51:22 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 16:51:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2007 16:48:10 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> In-Reply-To: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIP DHT interface (was HIP pros and cons) Thread-Index: Acg7Ta+A2jorms9SQCmhkUQXqT1NZQBCgTOw References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> From: "Henry Sinnreich" To: "Bruce Lowekamp" , "Miika Komu" X-OriginalArrivalTime: 12 Dec 2007 00:51:22.0251 (UTC) FILETIME=[1D5DEDB0:01C83C59] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: jeffrey.m.ahrenholz@boeing.com, p2psip@ietf.org Subject: [P2PSIP] HIP DHT interface (was HIP pros and cons) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce, >We need it to work in an environment without provisioned DNS support for=20 >the overlay and where we cannot assume an infrastructure provider providing >HIP relays. We need to be able to obtain those services from peers in the >overlay. So, minimally, this means the ability to support the HIP relay >functionality at the overlay layer. You are right. It appears this problem has been addressed in the I-D:=20 draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) Jeff: Is this I-D still available online and do you intend to resubmit an update? Henry -----Original Message----- From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com]=20 Sent: Monday, December 10, 2007 10:57 AM To: Miika Komu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons On Dec 7, 2007 7:43 PM, Miika Komu wrote: > Ali Fessi wrote: > > - apparently, it has been currently understood that using the HIT as a > > peer-id is not a good idea. (due to chosen-location attacks, etc..). so > > what's the advantage for using HIP? > > I am not sure about the issue here but does the chosen-location attack > have do anything with HIP? I think it is not really a HIP specific attack, > just something related to DHTs. > The chosen location attack is related to the method of generating a HIT from a node-generated key. As long as the HIT can be allocated by an enrollment server (or otherwise secured so that a single node cannot generate multiple or arbitrary HITs), there isn't a security problem here. If a node must be able to generate its own HIT, then the HIT cannot be used as a replacement for the peer-id in a DHT. > > And the main problem with HIP might be: > > > > - resolving a HIT to an IP address is actually a very similar problem as > > resolving a SIP URI to a Contact URI. And for HIP, this can be done by > > adding some infrastructure, like rendez-points, registrations > > extensions, DNS extensions, etc.. and *this HIP infrastructure is not > > there yet!* > > Agree partially, but I think this would make new business cases for > corporations from deploying infrastructure for customers. > > The DNS extensions are not mandatory. You can use opportunistic mode which > works in the similar leap-of-fait manner as ssh. Surely there's an option in between "use dns" and "use leap-of-faith" of using certificate chains? > > - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP > > or any P2P application anyway. > > I'd disagree here. It is possible to use ICE in P2P-SIP because it is > completely new application and not a legacy application. However, if you > think about it architecturally, why makes P2P-SIP so special that it must > burden itself with NAT traversal? Why cannot just use a NAT traversal > service transparently from the lower layers? > > I think the designers and implementors of P2P-SIP can concentrate better > to some P2P-SIP issues if NAT traversal is handled by someone else. > > > > If some people think that HIP is really a great idea for P2PSIP, then it > > should be also clear to the P2PSIP community what are all the > > consequences of using HIP, which additional infra do they need for using > > HIP, whether they need IPSec ESP support on each node, etc. > > Minimal requirements are that you need some HIP relays to transport the > HIP "offer/answer". Implementing NULL-ESP is trivial and supported by the > HIP specs. DNS extensions are not mandatory. > (I rearranged this a little bit to bring these two issues together.) One of the confusing things about applying HIP to p2psip is the layering issues required to address the deployment scenarios for p2psip. We need it to work in an environment without provisioned DNS support for the overlay and where we cannot assume an infrastructure provider providing HIP relays. We need to be able to obtain those services from peers in the overlay. So, minimally, this means the ability to support the HIP relay functionality at the overlay layer. This is where the proposal becomes confusing, because while HIP provides a very nice abstraction on top of which to build a p2p application, it also requires that p2p application for its connectivity. I've spent some time working with Philip on how to provide support for HIP inside of a p2psip peer protocol, and I think it's entirely doable, but I think we need to be clear on how the layering works and what support is needed in both directions before deciding how to accomplish it. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 06:11:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PV7-0007A9-Qe; Wed, 12 Dec 2007 06:11:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PV6-00079p-Jc for p2psip@ietf.org; Wed, 12 Dec 2007 06:11:40 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2PV5-0004fI-ND for p2psip@ietf.org; Wed, 12 Dec 2007 06:11:40 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 3FD562DED; Wed, 12 Dec 2007 13:11:39 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 283B72DB9; Wed, 12 Dec 2007 13:11:32 +0200 (EET) Date: Wed, 12 Dec 2007 13:11:32 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Ali Fessi Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <475D5824.103@uni-tuebingen.de> Message-ID: References: <475D5824.103@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 10 Dec 2007, Ali Fessi wrote: Hi, it cannot because IANA has allocated a special prefix for HIP: ftp://ftp.rfc-editor.org/in-notes/rfc4843.txt > Miika, > > thanks for the clarification. > > one question: what happens if the HIP identifier colludes with an IPv6 > address that is reserved for multicast, anycast, or e.g. local IPv6 > addresses? > > or does HIP generate several public/private pairs until it finds a good one? > > Cheers, > Ali > > > Miika Komu wrote: >> Ali Fessi wrote: >> >>> Hi all, >>> >>> just some comments >>> >>> (and maybe also questions to the HIP community who think that using HIP >>> for P2PSIP is a good idea) >>> >>> - apparently, it has been currently understood that using the HIT as a >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). so >>> what's the advantage for using HIP? >> >> I am not sure about the issue here but does the chosen-location attack have >> do anything with HIP? I think it is not really a HIP specific attack, just >> something related to DHTs. >> >>> - for NAT traversal: HIP is also doing ICE, which can be used for P2PSIP >>> or any P2P application anyway. >> >> I'd disagree here. It is possible to use ICE in P2P-SIP because it is >> completely new application and not a legacy application. However, if you >> think about it architecturally, why makes P2P-SIP so special that it must >> burden itself with NAT traversal? Why cannot just use a NAT traversal >> service transparently from the lower layers? >> >> I think the designers and implementors of P2P-SIP can concentrate better to >> some P2P-SIP issues if NAT traversal is handled by someone else. >> >>> - mobility can be achieved by a P2PSIP overlay easily once a P2PSIP >>> overlay is running. You can just update you current Contact URI. So here >>> again, there is no strong argument for HIP >> >> Disagree again here. Doesn't it still disconnect active phone calls? >> >> If you want to support mobility during phone calls in P2P-SIP, I'd ask the >> same question as before: what makes SIP such an special application that it >> needs its own host mobility mechanism? >> >>> And the main problem with HIP might be: >>> >>> - resolving a HIT to an IP address is actually a very similar problem as >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done by >>> adding some infrastructure, like rendez-points, registrations >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >>> there yet!* >> >> Agree partially, but I think this would make new business cases for >> corporations from deploying infrastructure for customers. >> >> The DNS extensions are not mandatory. You can use opportunistic mode which >> works in the similar leap-of-fait manner as ssh. >> >>> You can try to resolve the HIT to an IP address using a DHT (as >>> suggested in draft-ahrenholz-hiprg-dht-01 ). But you will probably turn >>> into the same problems as for P2PSIP again. So, you're just moving the >>> problems to some layers below. >> >> Well, isn't it the right layer for solving those problems? >> >>> If some people think that HIP is really a great idea for P2PSIP, then it >>> should be also clear to the P2PSIP community what are all the >>> consequences of using HIP, which additional infra do they need for using >>> HIP, whether they need IPSec ESP support on each node, etc. >> >> Minimal requirements are that you need some HIP relays to transport the HIP >> "offer/answer". Implementing NULL-ESP is trivial and supported by the HIP >> specs. DNS extensions are not mandatory. >> > > > -- > Ali Fessi > Computer Networks and Internet > University of Tuebingen, Germany > Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 > EMail: ali.fessi@uni-tuebingen.de > Web: http://net.informatik.uni-tuebingen.de/~fessi/ > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 06:11:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PV2-00078u-Eh; Wed, 12 Dec 2007 06:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PV0-00078l-3X for p2psip@ietf.org; Wed, 12 Dec 2007 06:11:34 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2PUx-0004f2-QO for p2psip@ietf.org; Wed, 12 Dec 2007 06:11:34 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 054792DD4; Wed, 12 Dec 2007 13:11:30 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1A06E2C81; Wed, 12 Dec 2007 13:11:22 +0200 (EET) Date: Wed, 12 Dec 2007 13:11:22 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Henry Sinnreich Subject: RE: [P2PSIP] Re: HIP pros and cons In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3C5@namail5.corp.adobe.com> Message-ID: References: <24CCCC428EFEA2469BF046DB3C7A8D223AE3C5@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Sun, 9 Dec 2007, Henry Sinnreich wrote: Hi, (sorry for the long delay in comments) >> If you want to support mobility during phone calls in P2P-SIP > > See > http://en.wikipedia.org/wiki/Media_independent_handover > >> I think the designers and implementors of P2P-SIP can concentrate > better to >some P2P-SIP issues if NAT traversal is handled by someone > else. Why cannot >just use a NAT traversal service transparently from > the lower layers? > > I fully agree. See the link above. Having MIH (micromobility) would be great, but it seems to me that it requires support both from the infrastructure (access points, core) and end-user equipment. I have no idea how widely deployed that stuff is. Minimally, HIP (macromobility) requires support only from the end-user equipment. Having both of them would be great. (There is also a paper called Micromobility support in HIP: survey and extension of host identity protocol by Novaczki et al) > As for ICE/STUN/TURN vs. HIP I would not exclude a synergy between the > two that can be devised, since the HIP security, mobility, multiplex, > etc. and applicability for any other application protocol are hard to > beat and IP also uses an ICE-like approach. > > http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-02.txt FYI, the HIP-NAT design team is going to use ICE (almost) as it is for NAT traversal at the lower layers to reuse ICE implementations. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 06:11:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PVM-0007cj-FL; Wed, 12 Dec 2007 06:11:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PVK-0007ZW-G1 for p2psip@ietf.org; Wed, 12 Dec 2007 06:11:54 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2PVJ-0004wn-NN for p2psip@ietf.org; Wed, 12 Dec 2007 06:11:54 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CAC152DD4; Wed, 12 Dec 2007 13:11:52 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 8679E2DB9; Wed, 12 Dec 2007 13:11:45 +0200 (EET) Date: Wed, 12 Dec 2007 13:11:45 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Bruce Lowekamp Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 10 Dec 2007, Bruce Lowekamp wrote: > On Dec 7, 2007 7:43 PM, Miika Komu wrote: >> Ali Fessi wrote: >>> - apparently, it has been currently understood that using the HIT as a >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). so >>> what's the advantage for using HIP? >> >> I am not sure about the issue here but does the chosen-location attack >> have do anything with HIP? I think it is not really a HIP specific attack, >> just something related to DHTs. > > The chosen location attack is related to the method of generating a > HIT from a node-generated key. As long as the HIT can be allocated by > an enrollment server (or otherwise secured so that a single node > cannot generate multiple or arbitrary HITs), there isn't a security > problem here. If a node must be able to generate its own HIT, then > the HIT cannot be used as a replacement for the peer-id in a DHT. What prevents a node from allocating keys from the enrollment server until it gets what it wants? Besides, there is an additional cost in using the HIT as the key. The HIT is generated from a public key and creation of public keys costs more than just generating a random key. >>> And the main problem with HIP might be: >>> >>> - resolving a HIT to an IP address is actually a very similar problem as >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done by >>> adding some infrastructure, like rendez-points, registrations >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >>> there yet!* >> >> Agree partially, but I think this would make new business cases for >> corporations from deploying infrastructure for customers. >> >> The DNS extensions are not mandatory. You can use opportunistic mode which >> works in the similar leap-of-fait manner as ssh. > > Surely there's an option in between "use dns" and "use leap-of-faith" > of using certificate chains? Surely, if you have PKI :) This has similar, or even worse, infrastructure requirements as DNS. > (I rearranged this a little bit to bring these two issues together.) > > One of the confusing things about applying HIP to p2psip is the > layering issues required to address the deployment scenarios for > p2psip. We need it to work in an environment without provisioned DNS > support for the overlay and where we cannot assume an infrastructure > provider providing HIP relays. We need to be able to obtain those > services from peers in the overlay. So, minimally, this means the > ability to support the HIP relay functionality at the overlay layer. > This is where the proposal becomes confusing, because while HIP > provides a very nice abstraction on top of which to build a p2p > application, it also requires that p2p application for its > connectivity. By p2p application you mean the overlay? HIP provides security and NAT traversal for the overlay and the overlay does what it does. Not a bad casting of roles? Assuming still that you mean the overlay, it would be possible to implement the overlay based on HIP, i.e. embed one or multiple DHT algorithms to HIP rendezvous forwarding architecture. I am sure that this alternative has been discussed earlier here. > HIP inside of a p2psip peer protocol, and I think it's entirely > doable, but I think we need to be clear on how the layering works and > what support is needed in both directions before deciding how to > accomplish it. This sounds like hi3 as long as we are talking about the overlay functionality: http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf http://www.tools.ietf.org/html/draft-nikander-hiprg-hi3-00 Certainly doable. At least OpenHIP and HIPL projects have implemented this. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 06:12:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PVl-0007pW-K0; Wed, 12 Dec 2007 06:12:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PVk-0007pJ-4B for p2psip@ietf.org; Wed, 12 Dec 2007 06:12:20 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2PVj-0004xa-Kh for p2psip@ietf.org; Wed, 12 Dec 2007 06:12:20 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2A95A2DD4; Wed, 12 Dec 2007 13:12:19 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D5DE22DDB; Wed, 12 Dec 2007 13:12:07 +0200 (EET) Date: Wed, 12 Dec 2007 13:12:07 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Roy, Radhika R Dr CTR USA USAMC" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <082601c83b58$9de2b3a0$f7168182@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 10 Dec 2007, Roy, Radhika R Dr CTR USA USAMC wrote: > Inline [RRR] > > ----- Original Message ----- > From: Spencer Dawkins > Date: Monday, December 10, 2007 13:16 > Subject: Re: [P2PSIP] Re: HIP pros and cons > To: p2psip@ietf.org > >>> One of the confusing things about applying HIP to p2psip is the >>> layering issues required to address the deployment scenarios for >>> p2psip. We need it to work in an environment without >> provisioned DNS >>> support for the overlay and where we cannot assume an infrastructure >>> provider providing HIP relays. We need to be able to obtain those >>> services from peers in the overlay. So, minimally, this means the >>> ability to support the HIP relay functionality at the overlay layer. >>> This is where the proposal becomes confusing, because while HIP >>> provides a very nice abstraction on top of which to build a p2p >>> application, it also requires that p2p application for its >>> connectivity. >>> >>> I've spent some time working with Philip on how to provide >> support for >>> HIP inside of a p2psip peer protocol, and I think it's entirely >>> doable, but I think we need to be clear on how the layering >> works and >>> what support is needed in both directions before deciding how to >>> accomplish it. >> >> I agree completely (on both "doable" and "need to be clear on how >> the >> layering works"). >> >> At a minumum, we could figure out whether we're running SIP over >> HIP or HIP >> over SIP... > > [RRR] Please help us to understand: What does it mean with respect to > the P2PSIP protocol when do the following: SIP over HIP or HIP-over-SIP? > > [RRR] Are you suggesting that the P2PSIP protocol will include the above > features as well as others defined in the requirement document, and the > combined protocol will still be called P2PSIP? I guess it means that HIP could be placed on three places in the stack: application | transport | <----- (1) Overlay routes HIP packets (like Hi3) overlay <----- (2) HIP-based overlay | <----- (3) HIP secures point-to-point connections ip for overlay nodes Does this clarify the situation? -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 09:59:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T3L-0005q4-VJ; Wed, 12 Dec 2007 09:59:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T3J-0005py-SZ for p2psip@ietf.org; Wed, 12 Dec 2007 09:59:13 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2T3I-00063J-Pv for p2psip@ietf.org; Wed, 12 Dec 2007 09:59:13 -0500 Received: by nz-out-0506.google.com with SMTP id n1so140918nzf.4 for ; Wed, 12 Dec 2007 06:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9nJqLimkk++hfGYlZ82bRLPqB3FVJFZ4u95CEhR78JU=; b=Rq+zY9aKTQlohB77A2diIfscxa3uLL5ggr+zSXTRQvYCJhZrF/Xm4aSWlbIl7Xc0AEIoaLu0/k3ytlD8lQnsnKYnJpPL2+0EGfHlzFSXFf3dlWnbYnadbDb4dV9g4P7kIwhRIQDKFu/3uLhczs3tYTvWewKQ0YwGrZvF248SBd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CTrFekzkVG0tk2S0Jo8MgCIi52pGIF2d73Ob+hJXceofm3fHA/l/ruxavr9wxmoeD1d31iDH0WY12fgXTl3J86bamUqASwqSiXmY6+6VFZEGZSWYK2XzzE5GXskpiIHpdBO5VuAxri9xHgVgjyiO4Ycg0JGzsgm40W426lfHKfw= Received: by 10.141.26.6 with SMTP id d6mr373822rvj.289.1197471551404; Wed, 12 Dec 2007 06:59:11 -0800 (PST) Received: by 10.141.40.5 with HTTP; Wed, 12 Dec 2007 06:59:11 -0800 (PST) Message-ID: <7b683f3f0712120659m5835fa83oa88a2a85ba43d351@mail.gmail.com> Date: Wed, 12 Dec 2007 09:59:11 -0500 From: "Eunsoo Shim" To: "Brian Rosen" Subject: Re: [P2PSIP] client protocol architectural issues In-Reply-To: <05cb01c83c0d$2e5d5890$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> <7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com> <20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com> <7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> <058c01c83bfe$eb48d510$640fa8c0@cis.neustar.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3D4@namail5.corp.adobe.com> <05cb01c83c0d$2e5d5890$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 11, 2007 10:47 AM, Brian Rosen wrote: > Henry > > Like most IETF work group, we're subject to scope creep. You are suggesting > scope creep; start working on non-SIP p2p before we have p2psip > standardized. > What do you mean by 'non-SIP p2p' and 'p2psip'? > You are free to propose a charter change. We'll see what support it gets. > > Right now, it's out of scope. It's relevant enough that we'll tolerate some > list discussion, but our scope is p2psip. > I think clients providing a storage function is as relevant to p2psip as clients not providing a storage function is. Thanks. Eunsoo > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Tuesday, December 11, 2007 10:24 AM > > To: Brian Rosen; lichun li; Bruce Lowekamp > > Cc: P2PSIP Mailing List > > Subject: RE: [P2PSIP] client protocol architectural issues > > > > I would like to sincerely congratulate the co-chairs for the excellent > > handling of the difficult WG meeting. Good job! > > > > But alas, nobody is perfect and I feel the client issue was handled in a > > heavy handed manner, showing an early manifest bias against clients and > > the client protocol. > > > > > but I don't want to spend > > > endless cycles debating the merits of proposals for #3 > > > > Option 3 is clearly the most interesting since it is the most powerful. > > > > If you put time and company resources into P2P, option 3 is just too > > important for "I don't want to spend endless cycles debating" and probably > > just have to do it. > > > > Since amending the WG charter was mentioned, the other applications, > > beyond SIP must also be taken into consideration, such as distributed > > directory and range searches as well as other applications that make the > > P2PSIP "call" more valuable. > > > > My two cents, > > > > Henry > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, December 11, 2007 6:06 AM > > To: 'lichun li'; 'Bruce Lowekamp' > > Cc: 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] client protocol architectural issues > > > > I refer you to the minutes of the IETF70 meeting held last week: > > "We will have clients that will have to do at least a get-put, all > > protocols > > will have to do that, and we'll not put a lot more meeting time into that > > for now" > > > > We observed that all of the proposed protocols have such an option > > defined. > > That is #2. We clearly permit #1. > > > > At the moment, we're probably not going to want to spend more time on > > option > > #3. If the chosen protocol has more, okay, but I don't want to spend > > endless cycles debating the merits of proposals for #3. > > > > Some list discussion on the subject is always interesting as long as we > > don't divert too much attention from more central issues. I'd prefer to > > see > > that discussion focused on specifics, rather than generalities, but open > > discussion is always welcome. > > > > Brian > > > > > > > > ________________________________________ > > From: lichun li [mailto:lilichun@gmail.com] > > Sent: Monday, December 10, 2007 8:26 PM > > To: Bruce Lowekamp > > Cc: P2PSIP Mailing List > > Subject: Re: [P2PSIP] client protocol architectural issues > > > > I also think option1 and 2 are necessary.Maybe only one type of node is > > calledas "client" eventually. Butthere should be more than one type of > > node in P2PSIP other than peer. > > > > > > On Dec 11, 2007 3:18 AM, Bruce Lowekamp wrote: > > Eunsoo, > > > > I'm sorry, I will try to be more clear. > > > > My initial statement was that there are a range of architectural > > options, which I listed as: > > - option 1: the only p2psip clients are sip devices that speak sip > > with p2psip peers > > - option 2: there is a get/put client protocol that allows non-sip > > interaction between clients and peers > > - option 3: there is a more complicated client protocol that allows > > "clients" to offer storage or other services to the peers > > > > > > The statement I made after that in my initial email was: > > > My personal belief is that the primary P2PSIP architecture should be > > (1). > > I still support this, for a few reasons. First, observe that I made > > that statement about P2P*SIP* (emphasis added). It's SIP. Discussion > > of non-SIP is further down. In a P2P*SIP* architecture, it seems > > reasonable to assume that many if not most of the devices will be SIP > > devices. For compatibility with existing SIP devices (which cannot > > possibly be peers), they will need a SIP proxy for connectivity, which > > will most probably be a P2PSIP device. So that's SIP being used as a > > "client" protocol. Most devices that can speak the peer protocol, I > > will assume will be peers. There are some arguments for why a P2PSIP > > device can't be a peer, as your draft points out, and for almost all > > of those scenarios, SIP will work fine. > > > > Now, there are a few deployment scenarios for P2PSIP where for some > > reason the clients can't use a P2PSIP peer as their proxy. Your draft > > listed some, and I think there are others. In those cases, I think > > option 2 is necessary. I think it's necessary, it's just that the > > default should be option 1. > > > > I should add that I am assuming that if we choose to support option 2, > > p2psip implementations are still free to support option 1, it's just > > that the peer protocol is required to support option 2 (client > > get/put). > > > > Now, for non-SIP, well, the quick answer is that we're not chartered > > to work on non-SIP. So that's not a question about P2P*SIP*. But the > > longer answer is that I suspect most non-SIP applications will already > > have their own protocol, and I still believe that the vast majority of > > deployment scenarios should require no more than option 2 (although > > there are obviously important applications of option 3 as well). > > > > Bruce > > > > > > On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > > > I don't quite understand how what you wrote below is connected to your > > > initial proposal that P2PSIP architecture should require all > > > devices/nodes (Peers and Clients) to be coupled with SIP entities. > > > Could you explain again the reason of your proposal? > > > Thanks. > > > > > > Eunsoo > > > > > > > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp wrote: > > > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp > > wrote: > > > > > > For P2PSIP, one option for "clients" is essentially for the peer > > to > > be > > > > > > acting as a proxy for clients that speak only SIP and be totally > > > > > > unaware of the overlay. > > > > > > > > > > Other protocols will likely have their own > > > > > > way of using the peer as a client without being aware of the > > overlay. > > > > > > > > > > > > > > > > This is a problem with removing the concept of Clients in the > > overlay > > layer. > > > > > If there is the Client node type, application protocols don't need > > to > > > > > have their own way to support client-like devices. > > > > > > > > > > > > > My point is very simple. Most applications that have been discussed > > > > already exist before a p2p version has been created. So they already > > > > have this protocol. > > > > > > > > > > > > > > > > > > 2 says that whatever the application is, the application will > > be > > able > > > > > > > > to use GET/STORE to provide provides the lookup and > > CONNECT/TUNNEL > > > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > > > > > 3 says that there is some need for these nodes to interact at > > a > > more > > > > > > > > basic, non-application way, that is not simply doing location > > for that > > > > > > > > application. It has nothing to do with non-SIP, it means that > > > > > > > > whatever the application is, it's non-application. > > > > > > > > > > > > > > > I don't understand this either. > > > > > > > > > > > > 2 is clients use the overlay's get/put. So they know the overlay > > > > > > exists and speak the p2p protocol, but don't provide storage to > > the > > > > > > overlay, they just use it to resolve lookups. > > > > > > > > > > > > 3 says that the clients will need to do more than just simple > > get/put. > > > > > > Trying to contribute storage to the peer would be the most > > obvious > > > > > > example of this. > > > > > > > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the > > overlay > > > > > layer may or may not be coupled with SIP entities. What you are > > > > > talking about is whether the Clients will do in the overlay layer > > more > > > > > than just using the overlay with GET/PUT. > > > > > > > > Exactly. SIP (since it's what we're chartered for) is just the > > > > primary working example of an application. > > > > > > > > Bruce > > > > > > > > > > > > > > > > -- > > > Eunsoo > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > -- > > Sincerely yours, > > > > Lichun Li > > Mobile Life New Media Lab, BUPT > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 11:13:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UDQ-00025r-NE; Wed, 12 Dec 2007 11:13:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UDO-00025i-TM for p2psip@ietf.org; Wed, 12 Dec 2007 11:13:42 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2UDO-0001Bd-GM for p2psip@ietf.org; Wed, 12 Dec 2007 11:13:42 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3863033C6D; Wed, 12 Dec 2007 08:08:13 -0800 (PST) Date: Wed, 12 Dec 2007 08:08:12 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071212160813.3863033C6D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Wed, 12 Dec 2007 13:11:45 +0200 (EET), Miika Komu wrote: > > On Mon, 10 Dec 2007, Bruce Lowekamp wrote: > > > On Dec 7, 2007 7:43 PM, Miika Komu wrote: > >> Ali Fessi wrote: > >>> - apparently, it has been currently understood that using the HIT as a > >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). so > >>> what's the advantage for using HIP? > >> > >> I am not sure about the issue here but does the chosen-location attack > >> have do anything with HIP? I think it is not really a HIP specific attack, > >> just something related to DHTs. > > > > The chosen location attack is related to the method of generating a > > HIT from a node-generated key. As long as the HIT can be allocated by > > an enrollment server (or otherwise secured so that a single node > > cannot generate multiple or arbitrary HITs), there isn't a security > > problem here. If a node must be able to generate its own HIT, then > > the HIT cannot be used as a replacement for the peer-id in a DHT. > > What prevents a node from allocating keys from the enrollment server until > it gets what it wants? Yes, you need to throttle queries somewhat at the enrollment server. But this is a much easier problem than throttling key generations which don't require a server query. > Besides, there is an additional cost in using the HIT as the key. The HIT > is generated from a public key and creation of public keys costs more than > just generating a random key. Not enough more to make a practical difference. Please see my talk in YVR for the relevant analysis. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 11:32:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UVm-0000Ve-4H; Wed, 12 Dec 2007 11:32:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UVk-0000Ub-2e for p2psip@ietf.org; Wed, 12 Dec 2007 11:32:40 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2UVh-0001Zh-T1 for p2psip@ietf.org; Wed, 12 Dec 2007 11:32:40 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBCGWSmR016314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Dec 2007 08:32:28 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBCGWSwr029943; Wed, 12 Dec 2007 08:32:28 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBCGWQHY029798; Wed, 12 Dec 2007 08:32:28 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 08:32:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Dec 2007 08:32:30 -0800 Message-ID: <0DF156EE7414494187B087A3C279BDB4080C4EB1@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIP DHT interface (was HIP pros and cons) Thread-Index: Acg7Ta+A2jorms9SQCmhkUQXqT1NZQBCgTOwACBterA= References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> From: "Ahrenholz, Jeffrey M" To: "Henry Sinnreich" , "Bruce Lowekamp" , "Miika Komu" X-OriginalArrivalTime: 12 Dec 2007 16:32:27.0686 (UTC) FILETIME=[95638C60:01C83CDC] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: p2psip@ietf.org Subject: [P2PSIP] RE: HIP DHT interface (was HIP pros and cons) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry, > It appears this problem has been addressed in the I-D:=20 > draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) >=20 > Jeff: Is this I-D still available online and do you intend to resubmit > an update? >=20 Although this -01 draft has expired, yes I plan to submit a -02 update based on comments (see hipsec-rg mailing list from August 2007). Here is the expired draft: http://www.watersprings.org/pub/id/draft-ahrenholz-hiprg-dht-01.txt Also, we have deployed a DHT server on our HIP test server at hipserver.mct.phantomworks.org. When testing HIP you can use that server or the OpenDHT ring available on PlanetLab. The idea with having our own server is that in the future we may modify the Bamboo DHT code slightly to perform increased security checks (see the "hip-secure-addr" application from the draft.) -Jeff _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 11:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UdD-0005Jb-K8; Wed, 12 Dec 2007 11:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UdC-0005Fc-Tr for p2psip@ietf.org; Wed, 12 Dec 2007 11:40:22 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2UdC-0001ne-NS for p2psip@ietf.org; Wed, 12 Dec 2007 11:40:22 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2Ucy-0008Q6-1P; Wed, 12 Dec 2007 11:40:08 -0500 In-Reply-To: <475D5824.103@uni-tuebingen.de> References: <475D5824.103@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D5DC00B-2FDF-453A-B2CF-EEFB13B7AECB@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Tue, 11 Dec 2007 16:32:47 -0800 To: Ali Fessi X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.8 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 10-Dec-07, at 07:15 , Ali Fessi wrote: > Miika, > > thanks for the clarification. > > one question: what happens if the HIP identifier colludes with an > IPv6 address that is reserved for multicast, anycast, or e.g. local > IPv6 addresses? > IANA has allocated a range of IPv6 addresses to use for HITs. Thus there no possibility of collision. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 11:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UiF-0003sc-Fp; Wed, 12 Dec 2007 11:45:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UiD-0003ga-Os for p2psip@ietf.org; Wed, 12 Dec 2007 11:45:33 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2UiC-00024g-UB for p2psip@ietf.org; Wed, 12 Dec 2007 11:45:33 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J2Uhw-00078k-LH; Wed, 12 Dec 2007 17:45:16 +0100 Message-ID: <47601019.6090103@uni-tuebingen.de> Date: Wed, 12 Dec 2007 17:45:13 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" Subject: Re: [P2PSIP] RE: HIP DHT interface (was HIP pros and cons) References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <0DF156EE7414494187B087A3C279BDB4080C4EB1@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB4080C4EB1@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: p2psip@ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, draft draft-ahrenholz-hiprg-dht is currenty an IRTF draft. Would it make sense to encourage the IETF HIP WG to work on this draft, since it could be useful for the P2PSIP WG? Cheers, Ali Ahrenholz, Jeffrey M wrote: > Henry, > >> It appears this problem has been addressed in the I-D: >> draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) >> >> Jeff: Is this I-D still available online and do you intend to resubmit >> an update? >> > > Although this -01 draft has expired, yes I plan to submit a -02 update > based on comments (see hipsec-rg mailing list from August 2007). Here is > the expired draft: > http://www.watersprings.org/pub/id/draft-ahrenholz-hiprg-dht-01.txt > > Also, we have deployed a DHT server on our HIP test server at > hipserver.mct.phantomworks.org. When testing HIP you can use that server > or the OpenDHT ring available on PlanetLab. The idea with having our own > server is that in the future we may modify the Bamboo DHT code slightly > to perform increased security checks (see the "hip-secure-addr" > application from the draft.) > > -Jeff > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 13:27:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2WIR-0006qt-CQ; Wed, 12 Dec 2007 13:27:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2WIP-0006qe-WF for p2psip@ietf.org; Wed, 12 Dec 2007 13:27:02 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2WIN-0005t7-Er for p2psip@ietf.org; Wed, 12 Dec 2007 13:27:01 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1J2WIE-0007bT-D5; Wed, 12 Dec 2007 12:26:51 -0600 From: "Brian Rosen" To: "'Eunsoo Shim'" References: <20d2bdfb0712051117j90564afod62ce41bfc4ebcd3@mail.gmail.com> <20d2bdfb0712060939s5eca798do97a9f68d7fcc585d@mail.gmail.com> <7b683f3f0712061028j4489892ajd5c560534684f6d1@mail.gmail.com> <20d2bdfb0712061100q2abe0a53gaa03aae5b3a6fe0a@mail.gmail.com> <7b683f3f0712070838u588df76em65a3745ec5675d45@mail.gmail.com> <20d2bdfb0712101118k4d604c38i78d735bd56fd7164@mail.gmail.com> <7d6b50690712101725s5bac7bb6k5b30484821e340ae@mail.gmail.com> <058c01c83bfe$eb48d510$640fa8c0@cis.neustar.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3D4@namail5.corp.adobe.com> <05cb01c83c0d$2e5d5890$640fa8c0@cis.neustar.com> <7b683f3f0712120659m5835fa83oa88a2a85ba43d351@mail.gmail.com> Subject: RE: [P2PSIP] client protocol architectural issues Date: Wed, 12 Dec 2007 13:26:49 -0500 Message-ID: <02bc01c83cec$91a90220$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acg8z65J7Au1ATRxSJu8dt36pByXeAAHHOXw In-Reply-To: <7b683f3f0712120659m5835fa83oa88a2a85ba43d351@mail.gmail.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > Sent: Wednesday, December 12, 2007 9:59 AM > To: Brian Rosen > Cc: Henry Sinnreich; lichun li; Bruce Lowekamp; P2PSIP Mailing List > Subject: Re: [P2PSIP] client protocol architectural issues > > On Dec 11, 2007 10:47 AM, Brian Rosen wrote: > > Henry > > > > Like most IETF work group, we're subject to scope creep. You are > suggesting > > scope creep; start working on non-SIP p2p before we have p2psip > > standardized. > > > What do you mean by 'non-SIP p2p' and 'p2psip'? p2psip <> non-SIP p2p We're working on the former, not the latter. > > > You are free to propose a charter change. We'll see what support it > gets. > > > > Right now, it's out of scope. It's relevant enough that we'll tolerate > some > > list discussion, but our scope is p2psip. > > > I think clients providing a storage function is as relevant to p2psip > as clients not providing a storage function is. The consensus at the meeting was: A client is a peer that does not do routing. There is no mention of "storage" in that definition. Some protocol proposals allowed clients to store or not store. That's ok, but not a requirement. Is that okay? Brian > > Thanks. > > Eunsoo > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Tuesday, December 11, 2007 10:24 AM > > > To: Brian Rosen; lichun li; Bruce Lowekamp > > > Cc: P2PSIP Mailing List > > > Subject: RE: [P2PSIP] client protocol architectural issues > > > > > > I would like to sincerely congratulate the co-chairs for the excellent > > > handling of the difficult WG meeting. Good job! > > > > > > But alas, nobody is perfect and I feel the client issue was handled in > a > > > heavy handed manner, showing an early manifest bias against clients > and > > > the client protocol. > > > > > > > but I don't want to spend > > > > endless cycles debating the merits of proposals for #3 > > > > > > Option 3 is clearly the most interesting since it is the most > powerful. > > > > > > If you put time and company resources into P2P, option 3 is just too > > > important for "I don't want to spend endless cycles debating" and > probably > > > just have to do it. > > > > > > Since amending the WG charter was mentioned, the other applications, > > > beyond SIP must also be taken into consideration, such as distributed > > > directory and range searches as well as other applications that make > the > > > P2PSIP "call" more valuable. > > > > > > My two cents, > > > > > > Henry > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, December 11, 2007 6:06 AM > > > To: 'lichun li'; 'Bruce Lowekamp' > > > Cc: 'P2PSIP Mailing List' > > > Subject: RE: [P2PSIP] client protocol architectural issues > > > > > > I refer you to the minutes of the IETF70 meeting held last week: > > > "We will have clients that will have to do at least a get-put, all > > > protocols > > > will have to do that, and we'll not put a lot more meeting time into > that > > > for now" > > > > > > We observed that all of the proposed protocols have such an option > > > defined. > > > That is #2. We clearly permit #1. > > > > > > At the moment, we're probably not going to want to spend more time on > > > option > > > #3. If the chosen protocol has more, okay, but I don't want to spend > > > endless cycles debating the merits of proposals for #3. > > > > > > Some list discussion on the subject is always interesting as long as > we > > > don't divert too much attention from more central issues. I'd prefer > to > > > see > > > that discussion focused on specifics, rather than generalities, but > open > > > discussion is always welcome. > > > > > > Brian > > > > > > > > > > > > ________________________________________ > > > From: lichun li [mailto:lilichun@gmail.com] > > > Sent: Monday, December 10, 2007 8:26 PM > > > To: Bruce Lowekamp > > > Cc: P2PSIP Mailing List > > > Subject: Re: [P2PSIP] client protocol architectural issues > > > > > > I also think option1 and 2 are necessary.Maybe only one type of node > is > > > calledas "client" eventually. Butthere should be more than one type of > > > node in P2PSIP other than peer. > > > > > > > > > On Dec 11, 2007 3:18 AM, Bruce Lowekamp > wrote: > > > Eunsoo, > > > > > > I'm sorry, I will try to be more clear. > > > > > > My initial statement was that there are a range of architectural > > > options, which I listed as: > > > - option 1: the only p2psip clients are sip devices that speak sip > > > with p2psip peers > > > - option 2: there is a get/put client protocol that allows non-sip > > > interaction between clients and peers > > > - option 3: there is a more complicated client protocol that allows > > > "clients" to offer storage or other services to the peers > > > > > > > > > The statement I made after that in my initial email was: > > > > My personal belief is that the primary P2PSIP architecture should be > > > (1). > > > I still support this, for a few reasons. First, observe that I made > > > that statement about P2P*SIP* (emphasis added). It's SIP. Discussion > > > of non-SIP is further down. In a P2P*SIP* architecture, it seems > > > reasonable to assume that many if not most of the devices will be SIP > > > devices. For compatibility with existing SIP devices (which cannot > > > possibly be peers), they will need a SIP proxy for connectivity, which > > > will most probably be a P2PSIP device. So that's SIP being used as a > > > "client" protocol. Most devices that can speak the peer protocol, I > > > will assume will be peers. There are some arguments for why a P2PSIP > > > device can't be a peer, as your draft points out, and for almost all > > > of those scenarios, SIP will work fine. > > > > > > Now, there are a few deployment scenarios for P2PSIP where for some > > > reason the clients can't use a P2PSIP peer as their proxy. Your draft > > > listed some, and I think there are others. In those cases, I think > > > option 2 is necessary. I think it's necessary, it's just that the > > > default should be option 1. > > > > > > I should add that I am assuming that if we choose to support option 2, > > > p2psip implementations are still free to support option 1, it's just > > > that the peer protocol is required to support option 2 (client > > > get/put). > > > > > > Now, for non-SIP, well, the quick answer is that we're not chartered > > > to work on non-SIP. So that's not a question about P2P*SIP*. But the > > > longer answer is that I suspect most non-SIP applications will already > > > have their own protocol, and I still believe that the vast majority of > > > deployment scenarios should require no more than option 2 (although > > > there are obviously important applications of option 3 as well). > > > > > > Bruce > > > > > > > > > On Dec 7, 2007 11:38 AM, Eunsoo Shim wrote: > > > > I don't quite understand how what you wrote below is connected to > your > > > > initial proposal that P2PSIP architecture should require all > > > > devices/nodes (Peers and Clients) to be coupled with SIP entities. > > > > Could you explain again the reason of your proposal? > > > > Thanks. > > > > > > > > Eunsoo > > > > > > > > > > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp > wrote: > > > > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> > wrote: > > > > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp > > > > wrote: > > > > > > > For P2PSIP, one option for "clients" is essentially for the > peer > > > to > > > be > > > > > > > acting as a proxy for clients that speak only SIP and be > totally > > > > > > > unaware of the overlay. > > > > > > > > > > > > Other protocols will likely have their own > > > > > > > way of using the peer as a client without being aware of the > > > overlay. > > > > > > > > > > > > > > > > > > > This is a problem with removing the concept of Clients in the > > > overlay > > > layer. > > > > > > If there is the Client node type, application protocols don't > need > > > to > > > > > > have their own way to support client-like devices. > > > > > > > > > > > > > > > > My point is very simple. Most applications that have been > discussed > > > > > already exist before a p2p version has been created. So they > already > > > > > have this protocol. > > > > > > > > > > > > > > > > > > > > > 2 says that whatever the application is, the application > will > > > be > > > able > > > > > > > > > to use GET/STORE to provide provides the lookup and > > > CONNECT/TUNNEL > > > > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > > > > > > > 3 says that there is some need for these nodes to interact > at > > > a > > > more > > > > > > > > > basic, non-application way, that is not simply doing > location > > > for that > > > > > > > > > application. It has nothing to do with non-SIP, it means > that > > > > > > > > > whatever the application is, it's non-application. > > > > > > > > > > > > > > > > > I don't understand this either. > > > > > > > > > > > > > > 2 is clients use the overlay's get/put. So they know the > overlay > > > > > > > exists and speak the p2p protocol, but don't provide storage > to > > > the > > > > > > > overlay, they just use it to resolve lookups. > > > > > > > > > > > > > > 3 says that the clients will need to do more than just simple > > > get/put. > > > > > > > Trying to contribute storage to the peer would be the most > > > obvious > > > > > > > example of this. > > > > > > > > > > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in the > > > overlay > > > > > > layer may or may not be coupled with SIP entities. What you are > > > > > > talking about is whether the Clients will do in the overlay > layer > > > more > > > > > > than just using the overlay with GET/PUT. > > > > > > > > > > Exactly. SIP (since it's what we're chartered for) is just the > > > > > primary working example of an application. > > > > > > > > > > Bruce > > > > > > > > > > > > > > > > > > > > > -- > > > > Eunsoo > > > > > > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > -- > > > Sincerely yours, > > > > > > Lichun Li > > > Mobile Life New Media Lab, BUPT > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 15:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xzl-0003jV-At; Wed, 12 Dec 2007 15:15:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Xzk-0003fL-H8 for p2psip@ietf.org; Wed, 12 Dec 2007 15:15:52 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Xzj-0000Vl-Re for p2psip@ietf.org; Wed, 12 Dec 2007 15:15:52 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2Xzf-00020g-2y; Wed, 12 Dec 2007 15:15:47 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Wed, 12 Dec 2007 15:15:45 -0500 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry: Though the below mentioned work on DHTs is similar to what P2PSIP is looking at, none of the three proposals for using HIP for P2PSIP published so far make use of it. - Philip On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > Bruce, > >> We need it to work in an environment without provisioned DNS support > for >> the overlay and where we cannot assume an infrastructure provider > providing >HIP relays. We need to be able to obtain those services > from > peers in the >overlay. So, minimally, this means the ability to > support > the HIP relay >functionality at the overlay layer. > > You are right. > > It appears this problem has been addressed in the I-D: > draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) > > Jeff: Is this I-D still available online and do you intend to resubmit > an update? > > Henry > > -----Original Message----- > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > Sent: Monday, December 10, 2007 10:57 AM > To: Miika Komu > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > On Dec 7, 2007 7:43 PM, Miika Komu wrote: >> Ali Fessi wrote: >>> - apparently, it has been currently understood that using the HIT as > a >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). > so >>> what's the advantage for using HIP? >> >> I am not sure about the issue here but does the chosen-location >> attack >> have do anything with HIP? I think it is not really a HIP specific > attack, >> just something related to DHTs. >> > > > The chosen location attack is related to the method of generating a > HIT from a node-generated key. As long as the HIT can be allocated by > an enrollment server (or otherwise secured so that a single node > cannot generate multiple or arbitrary HITs), there isn't a security > problem here. If a node must be able to generate its own HIT, then > the HIT cannot be used as a replacement for the peer-id in a DHT. > > > > >>> And the main problem with HIP might be: >>> >>> - resolving a HIT to an IP address is actually a very similar > problem as >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done > by >>> adding some infrastructure, like rendez-points, registrations >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is > not >>> there yet!* >> >> Agree partially, but I think this would make new business cases for >> corporations from deploying infrastructure for customers. >> >> The DNS extensions are not mandatory. You can use opportunistic mode > which >> works in the similar leap-of-fait manner as ssh. > > Surely there's an option in between "use dns" and "use leap-of-faith" > of using certificate chains? > > > >>> - for NAT traversal: HIP is also doing ICE, which can be used for > P2PSIP >>> or any P2P application anyway. >> >> I'd disagree here. It is possible to use ICE in P2P-SIP because it is >> completely new application and not a legacy application. However, if > you >> think about it architecturally, why makes P2P-SIP so special that it > must >> burden itself with NAT traversal? Why cannot just use a NAT traversal >> service transparently from the lower layers? >> >> I think the designers and implementors of P2P-SIP can concentrate > better >> to some P2P-SIP issues if NAT traversal is handled by someone else. >> >> >>> If some people think that HIP is really a great idea for P2PSIP, > then it >>> should be also clear to the P2PSIP community what are all the >>> consequences of using HIP, which additional infra do they need for > using >>> HIP, whether they need IPSec ESP support on each node, etc. >> >> Minimal requirements are that you need some HIP relays to transport > the >> HIP "offer/answer". Implementing NULL-ESP is trivial and supported by > the >> HIP specs. DNS extensions are not mandatory. >> > > (I rearranged this a little bit to bring these two issues together.) > > One of the confusing things about applying HIP to p2psip is the > layering issues required to address the deployment scenarios for > p2psip. We need it to work in an environment without provisioned DNS > support for the overlay and where we cannot assume an infrastructure > provider providing HIP relays. We need to be able to obtain those > services from peers in the overlay. So, minimally, this means the > ability to support the HIP relay functionality at the overlay layer. > This is where the proposal becomes confusing, because while HIP > provides a very nice abstraction on top of which to build a p2p > application, it also requires that p2p application for its > connectivity. > > I've spent some time working with Philip on how to provide support for > HIP inside of a p2psip peer protocol, and I think it's entirely > doable, but I think we need to be clear on how the layering works and > what support is needed in both directions before deciding how to > accomplish it. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 17:10:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Zm9-0003QM-Gj; Wed, 12 Dec 2007 17:09:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Zm8-0003QG-Kk for p2psip@ietf.org; Wed, 12 Dec 2007 17:09:56 -0500 Received: from exprod6og105.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Zm6-0004Sw-L4 for p2psip@ietf.org; Wed, 12 Dec 2007 17:09:56 -0500 Received: from source ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP; Wed, 12 Dec 2007 14:09:49 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBCM7U12004692; Wed, 12 Dec 2007 14:07:30 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBCM9hRC008944; Wed, 12 Dec 2007 14:09:43 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 14:09:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Wed, 12 Dec 2007 14:09:37 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> In-Reply-To: <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP DHT interface (was HIP pros and cons) Thread-Index: Acg8+89aaaPcA8BLTryBZwOayZukHQAD4uNA References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 12 Dec 2007 22:09:43.0944 (UTC) FILETIME=[B3237880:01C83D0B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, >none of the three proposals for using HIP for P2PSIP =20 >published so far make use of it. Shouldn't we look at synergies between the _four_ efforts? Maybe some separate session would be worth while. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, December 12, 2007 2:16 PM To: Henry Sinnreich Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; p2psip@ietf.org Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) Henry: Though the below mentioned work on DHTs is similar to what P2PSIP is =20 looking at, none of the three proposals for using HIP for P2PSIP =20 published so far make use of it. - Philip On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > Bruce, > >> We need it to work in an environment without provisioned DNS support > for >> the overlay and where we cannot assume an infrastructure provider > providing >HIP relays. We need to be able to obtain those services =20 > from > peers in the >overlay. So, minimally, this means the ability to =20 > support > the HIP relay >functionality at the overlay layer. > > You are right. > > It appears this problem has been addressed in the I-D: > draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) > > Jeff: Is this I-D still available online and do you intend to resubmit > an update? > > Henry > > -----Original Message----- > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > Sent: Monday, December 10, 2007 10:57 AM > To: Miika Komu > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > On Dec 7, 2007 7:43 PM, Miika Komu wrote: >> Ali Fessi wrote: >>> - apparently, it has been currently understood that using the HIT as > a >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). > so >>> what's the advantage for using HIP? >> >> I am not sure about the issue here but does the chosen-location =20 >> attack >> have do anything with HIP? I think it is not really a HIP specific > attack, >> just something related to DHTs. >> > > > The chosen location attack is related to the method of generating a > HIT from a node-generated key. As long as the HIT can be allocated by > an enrollment server (or otherwise secured so that a single node > cannot generate multiple or arbitrary HITs), there isn't a security > problem here. If a node must be able to generate its own HIT, then > the HIT cannot be used as a replacement for the peer-id in a DHT. > > > > >>> And the main problem with HIP might be: >>> >>> - resolving a HIT to an IP address is actually a very similar > problem as >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done > by >>> adding some infrastructure, like rendez-points, registrations >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is > not >>> there yet!* >> >> Agree partially, but I think this would make new business cases for >> corporations from deploying infrastructure for customers. >> >> The DNS extensions are not mandatory. You can use opportunistic mode > which >> works in the similar leap-of-fait manner as ssh. > > Surely there's an option in between "use dns" and "use leap-of-faith" > of using certificate chains? > > > >>> - for NAT traversal: HIP is also doing ICE, which can be used for > P2PSIP >>> or any P2P application anyway. >> >> I'd disagree here. It is possible to use ICE in P2P-SIP because it is >> completely new application and not a legacy application. However, if > you >> think about it architecturally, why makes P2P-SIP so special that it > must >> burden itself with NAT traversal? Why cannot just use a NAT traversal >> service transparently from the lower layers? >> >> I think the designers and implementors of P2P-SIP can concentrate > better >> to some P2P-SIP issues if NAT traversal is handled by someone else. >> >> >>> If some people think that HIP is really a great idea for P2PSIP, > then it >>> should be also clear to the P2PSIP community what are all the >>> consequences of using HIP, which additional infra do they need for > using >>> HIP, whether they need IPSec ESP support on each node, etc. >> >> Minimal requirements are that you need some HIP relays to transport > the >> HIP "offer/answer". Implementing NULL-ESP is trivial and supported by > the >> HIP specs. DNS extensions are not mandatory. >> > > (I rearranged this a little bit to bring these two issues together.) > > One of the confusing things about applying HIP to p2psip is the > layering issues required to address the deployment scenarios for > p2psip. We need it to work in an environment without provisioned DNS > support for the overlay and where we cannot assume an infrastructure > provider providing HIP relays. We need to be able to obtain those > services from peers in the overlay. So, minimally, this means the > ability to support the HIP relay functionality at the overlay layer. > This is where the proposal becomes confusing, because while HIP > provides a very nice abstraction on top of which to build a p2p > application, it also requires that p2p application for its > connectivity. > > I've spent some time working with Philip on how to provide support for > HIP inside of a p2psip peer protocol, and I think it's entirely > doable, but I think we need to be clear on how the layering works and > what support is needed in both directions before deciding how to > accomplish it. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 18:01:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2aZg-0007HB-2K; Wed, 12 Dec 2007 18:01:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2aZe-0007Gx-U1 for p2psip@ietf.org; Wed, 12 Dec 2007 18:01:06 -0500 Received: from wr-out-0506.google.com ([64.233.184.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2aZe-0007ki-M1 for p2psip@ietf.org; Wed, 12 Dec 2007 18:01:06 -0500 Received: by wr-out-0506.google.com with SMTP id 68so210816wra.13 for ; Wed, 12 Dec 2007 15:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=EqjM8UrBCz38hUAsvUV40o8hQW9+FKMOIwa0EBIKayI=; b=nnD2yRGK2BRcs6/51EdciRLWPFm5VgykXeG1Y7CNM2lu5QeVUyR/65i46HH+KFiHqWnsMl0V1Xrob/5FmBYicb+ap+N2WAxyVN7uoRDc8BWB/OJGqZb5fKNP5Nppu4F2v8u3yK7aeAaN4Un5VK6bsmOi5FGlYz3gEQslXWD02U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gj87gIpZ9xp27RxEDorRf0oEub+43nWmUKr/nr+qp0wwTvj2u3rMZ4VRLJAoAvVrvHD/iumEburU2eET5QKAGFWeUSmWKtNqhoQlgbCPr4K1+0BmBdQFfFLK3rGB7hEqgHbESVtznNSc67194zsux6O3uNCtHJ+26KB8EzToLKo= Received: by 10.142.131.18 with SMTP id e18mr620309wfd.36.1197500464856; Wed, 12 Dec 2007 15:01:04 -0800 (PST) Received: by 10.142.132.18 with HTTP; Wed, 12 Dec 2007 15:00:37 -0800 (PST) Message-ID: <20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> Date: Wed, 12 Dec 2007 18:00:37 -0500 From: "Bruce Lowekamp" To: "Wei Gengyu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <000c01c83bf2$3aa1dd30$da07740a@dellwei> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <000c01c83bf2$3aa1dd30$da07740a@dellwei> X-Google-Sender-Auth: f6826a36f1b85d81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Gengyu, On Dec 11, 2007 7:34 AM, Wei Gengyu wrote: > When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay, > you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address. > So you conclude that you need to do mapping at the P2PSIP overlay. In this situation HIP is required. > Do I understand it right? > I'm not sure what you mean by P2PNS there. I think all of the peer protocol proposals have ways of searching in the overlay and establishing a connection with a specific peer. Certainly reload does. HIP isn't needed to solve that problem. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 18:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2aa4-0007eB-Q5; Wed, 12 Dec 2007 18:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2aa3-0007e4-Av for p2psip@ietf.org; Wed, 12 Dec 2007 18:01:31 -0500 Received: from hs-out-0708.google.com ([64.233.178.247] helo=hs-out-2122.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2aa1-0005kl-S4 for p2psip@ietf.org; Wed, 12 Dec 2007 18:01:31 -0500 Received: by hs-out-2122.google.com with SMTP id 54so424043hsz.5 for ; Wed, 12 Dec 2007 15:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=EqjM8UrBCz38hUAsvUV40o8hQW9+FKMOIwa0EBIKayI=; b=WPZPmxboKhMsMjXDPclTvGdUt+X4Fe/nolBhMuPn0sVck3DijmGmWP/I0I+OgL5ttMtpeJTTRbFA0aF/oTTG21l8mjWXgHiwir6Ny1Qt2SSuKQ92Kp8OJDSXnGDeekghHbMuSZCBPWC2URUzgEaF0O5rzyLLSVyKN5FUt7C+Jfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gj87gIpZ9xp27RxEDorRf0oEub+43nWmUKr/nr+qp0wwTvj2u3rMZ4VRLJAoAvVrvHD/iumEburU2eET5QKAGFWeUSmWKtNqhoQlgbCPr4K1+0BmBdQFfFLK3rGB7hEqgHbESVtznNSc67194zsux6O3uNCtHJ+26KB8EzToLKo= Received: by 10.142.135.9 with SMTP id i9mr615908wfd.212.1197500437845; Wed, 12 Dec 2007 15:00:37 -0800 (PST) Received: by 10.142.132.18 with HTTP; Wed, 12 Dec 2007 15:00:37 -0800 (PST) Message-ID: <20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> Date: Wed, 12 Dec 2007 18:00:37 -0500 From: "Bruce Lowekamp" To: "Wei Gengyu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <000c01c83bf2$3aa1dd30$da07740a@dellwei> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <000c01c83bf2$3aa1dd30$da07740a@dellwei> X-Google-Sender-Auth: f6826a36f1b85d81 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Gengyu, On Dec 11, 2007 7:34 AM, Wei Gengyu wrote: > When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay, > you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address. > So you conclude that you need to do mapping at the P2PSIP overlay. In this situation HIP is required. > Do I understand it right? > I'm not sure what you mean by P2PNS there. I think all of the peer protocol proposals have ways of searching in the overlay and establishing a connection with a specific peer. Certainly reload does. HIP isn't needed to solve that problem. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 12 18:21:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2atP-0007CH-Le; Wed, 12 Dec 2007 18:21:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2atO-0007CB-B7 for p2psip@ietf.org; Wed, 12 Dec 2007 18:21:30 -0500 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2atN-0006wk-Kw for p2psip@ietf.org; Wed, 12 Dec 2007 18:21:30 -0500 Received: by wr-out-0506.google.com with SMTP id 68so219417wra.13 for ; Wed, 12 Dec 2007 15:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=uw6Pytbxy3TFojCqR3cyAupS9LVjKzoXNvvekU7rdKc=; b=UHYbLJpDIgp1/aNJXGd3q3ZxxlSnlRw5LZj3iJisIXvx2N3JhR0bzn7hqlkjzcK/sEBOEaS3bpbpvRA3N56IeJ4pw2ERFv4l4xsSkmEpW7jBuQaH67WYFC2/nxxYoIemPkxa9iZIv5T9KPytrtZAVN7XOXieQlZ29zrvqheBlXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZFVG38fZNlfyArLrssZ/z2tKClMzd9OnhQLcbvk1MQIcrtAtyPVY4o4bqqkN8sYb9B2NTn9E8c2bs4PrYClPZfFhkn6rGGzfcGgDG8YK/u+QgF+zTUI8APcigJePzrO7NJkRFazdYeQaC8KQ5I0fRhBbTGrc5YgzC0nDxoN+vZg= Received: by 10.142.47.6 with SMTP id u6mr623026wfu.29.1197501687550; Wed, 12 Dec 2007 15:21:27 -0800 (PST) Received: by 10.142.132.18 with HTTP; Wed, 12 Dec 2007 15:21:27 -0800 (PST) Message-ID: <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> Date: Wed, 12 Dec 2007 18:21:27 -0500 From: "Bruce Lowekamp" To: "Miika Komu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> X-Google-Sender-Auth: 7d09e85fb53f0d75 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 12, 2007 6:11 AM, Miika Komu wrote: > On Mon, 10 Dec 2007, Bruce Lowekamp wrote: > >>> And the main problem with HIP might be: > >>> > >>> - resolving a HIT to an IP address is actually a very similar problem as > >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done by > >>> adding some infrastructure, like rendez-points, registrations > >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is not > >>> there yet!* > >> > >> Agree partially, but I think this would make new business cases for > >> corporations from deploying infrastructure for customers. > >> > >> The DNS extensions are not mandatory. You can use opportunistic mode which > >> works in the similar leap-of-fait manner as ssh. > > > > Surely there's an option in between "use dns" and "use leap-of-faith" > > of using certificate chains? > > Surely, if you have PKI :) This has similar, or even worse, infrastructure > requirements as DNS. > Sorry, but I completely disagree here. An enrollment server generating certificates requires one-time communication. The enrollment server itself is trivial to write (ignoring how you authenticate requesters, which will vary by the security model of the overlay). It's a trivial addition that could even be provided with every UA if desired for ad hoc environments. > > (I rearranged this a little bit to bring these two issues together.) > > > > One of the confusing things about applying HIP to p2psip is the > > layering issues required to address the deployment scenarios for > > p2psip. We need it to work in an environment without provisioned DNS > > support for the overlay and where we cannot assume an infrastructure > > provider providing HIP relays. We need to be able to obtain those > > services from peers in the overlay. So, minimally, this means the > > ability to support the HIP relay functionality at the overlay layer. > > This is where the proposal becomes confusing, because while HIP > > provides a very nice abstraction on top of which to build a p2p > > application, it also requires that p2p application for its > > connectivity. > > By p2p application you mean the overlay? HIP provides security and NAT > traversal for the overlay and the overlay does what it does. Not a bad > casting of roles? > Except that the overlay is still needed for rendezvous. Once you have that, the nat traversal really isn't hard. > > > HIP inside of a p2psip peer protocol, and I think it's entirely > > doable, but I think we need to be clear on how the layering works and > > what support is needed in both directions before deciding how to > > accomplish it. > > This sounds like hi3 as long as we are talking about the overlay > functionality: > > http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf > http://www.tools.ietf.org/html/draft-nikander-hiprg-hi3-00 > > Certainly doable. At least OpenHIP and HIPL projects have implemented > this. > I'd be interested in how that's implemented. From what I can see, the original papers simply assume the existence of Secure-i3 for rendezvous, and I don't see detailed enough docs from OpenHIP or HIPL for me to tell how they've implemented it. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 01:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hxV-0004om-WB; Thu, 13 Dec 2007 01:54:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hxU-0004o0-L7 for p2psip@ietf.org; Thu, 13 Dec 2007 01:54:12 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2hxR-0008Il-MY for p2psip@ietf.org; Thu, 13 Dec 2007 01:54:12 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ002GC74TJ6@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 14:53:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00CIG74S8B@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 14:53:17 +0800 (CST) Received: from z52048 ([10.164.5.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ00IKA74OHZ@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 14:53:16 +0800 (CST) Date: Thu, 13 Dec 2007 14:53:12 +0800 From: Zheng Hewen To: 'P2PSIP Mailing List' Message-id: <005e01c83d54$d472ce20$5405a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: Acg9UyYMEQiL5FvAQz22wqON+dhNoQAAGMGA X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [P2PSIP] An I-D about P2PSIP client protocol, any comment is appreciated. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We extended our peer protocol (SEP: Service Extensible P2P Peer P= rotocol,=20 http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) to imp= lement P2PSIP client protocol=20 (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-client-protoc= ol-00.txt). This document defines P2PSIP client protocol, one protocol for cl= ient-peer communication, which is used to create,=20 implement and maintain the services between a client and its associat= ed peer. This client protocol mainly two types of functions: data operatio= n (Put, Get, Remove) and the association maintenance=20 (Inquire, Join, Keep-alive, Notify, Leave). Among them, Join message = is used to implement admission control, Keep-alive=20 message and/or Notify message mainly are used to implement graceful s= witchover when a client is associated with more than one=20 peer. Any comment is appreciated. Best regards, Hewen > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 2007=C4=EA12=D4=C213=C8=D5 14:40 > To: hwzheng@huawei.com > Cc: jiang.x.f@huawei.com > Subject: New Version Notification for > draft-zheng-p2psip-client-protocol-00 > > > A new version of I-D, > draft-zheng-p2psip-client-protocol-00.txt has been > successfuly submitted by Hewen Zhang and posted to the IETF > repository. > > Filename:=09 draft-zheng-p2psip-client-protocol > Revision:=09 00 > Title:=09=09 P2PSIP Client Protocol > Creation_date:=09 2007-12-11 > WG ID:=09=09 Independent Submission > Number_of_pages: 31 > > Abstract: > This document defines P2PSIP client protocol, one protocol > for client-peer communication, which is used to create, > implement and maintain the services between a client and its > associated peer. > > > > > The IETF Secretariat. > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 02:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2i4L-0008W5-3g; Thu, 13 Dec 2007 02:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2i4J-0008Vz-6S for p2psip@ietf.org; Thu, 13 Dec 2007 02:01:15 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2i4H-0008W4-0W for p2psip@ietf.org; Thu, 13 Dec 2007 02:01:15 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ0082M7GDS3@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 15:00:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ0097T7GC1F@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 15:00:13 +0800 (CST) Received: from z52048 ([10.164.5.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ00IKL7G9HZ@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 15:00:12 +0800 (CST) Date: Thu, 13 Dec 2007 15:00:09 +0800 From: Zheng Hewen To: 'P2PSIP Mailing List' Message-id: <005f01c83d55$ccb927a0$5405a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: Acg9UjN1tvQVMcSLSgqwZ546/JkO0AAArN3w X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is appreciated. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We extended our peer protocol (SEP: Service Extensible P2P Peer P= rotocol,=20 http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) to imp= lement P2PSIP diagnosis=20 (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-diagnose-00.t= xt). This document describes a simple and efficient mechanism that can= be used to detect and localize failures in P2PSIP=20 overlay network. This document mainly consists of two parts: informa= tion carried in a P2PSIP Peer "Echo request" message and=20 "Echo response" message for the purpose of fault detection and locali= zation, and mechanisms for processing those messages. Any comment is appreciated. BTW, this I-D was finished before IETF70 as P2PSIP client protocol= =20 (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-client-protoc= ol-00.txt), they failed to be submitted due to mail=20 server, we have to submit them today through https://datatracker.ietf= .org/idst/upload.cgi after only changing creation date=20 according to "IETF Internet-Draft Submission tool's requirement". Best regards, Hewen > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 2007=C4=EA12=D4=C213=C8=D5 14:33 > To: hwzheng@huawei.com > Cc: jiang.x.f@huawei.com > Subject: New Version Notification for draft-zheng-p2psip-diagnose-0= 0 > > > A new version of I-D, draft-zheng-p2psip-diagnose-00.txt has > been successfuly submitted by Hewen Zhang and posted to the > IETF repository. > > Filename:=09 draft-zheng-p2psip-diagnose > Revision:=09 00 > Title:=09=09 Diagnose P2PSIP Overlay Network Failures > Creation_date:=09 2007-12-11 > WG ID:=09=09 Independent Submission > Number_of_pages: 21 > > Abstract: > This document describes a simple and efficient mechanism that > can be used to detect and localize failures in P2PSIP overlay > network. This document mainly consists of two parts: > information carried in a P2PSIP Peer "Echo request" message > and "Echo response" message for the purpose of fault > detection and localization, and mechanisms for processing > those messages. > > > > > The IETF Secretariat. > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 02:29:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2iVv-00017A-T1; Thu, 13 Dec 2007 02:29:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2iVt-00013d-Gd for p2psip@ietf.org; Thu, 13 Dec 2007 02:29:45 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2iVt-0000el-26 for p2psip@ietf.org; Thu, 13 Dec 2007 02:29:45 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 973402DF6; Thu, 13 Dec 2007 09:29:44 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A8E8A2DF6; Thu, 13 Dec 2007 09:29:37 +0200 (EET) Date: Thu, 13 Dec 2007 09:29:37 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20071212160813.3863033C6D@delta.rtfm.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Samu Varjonen , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Wed, 12 Dec 2007, Eric Rescorla wrote: Hi Eric, > At Wed, 12 Dec 2007 13:11:45 +0200 (EET), > Miika Komu wrote: >> >> On Mon, 10 Dec 2007, Bruce Lowekamp wrote: >> >>> On Dec 7, 2007 7:43 PM, Miika Komu wrote: >>>> Ali Fessi wrote: >>>>> - apparently, it has been currently understood that using the HIT as a >>>>> peer-id is not a good idea. (due to chosen-location attacks, etc..). so >>>>> what's the advantage for using HIP? >>>> >>>> I am not sure about the issue here but does the chosen-location attack >>>> have do anything with HIP? I think it is not really a HIP specific attack, >>>> just something related to DHTs. >>> >>> The chosen location attack is related to the method of generating a >>> HIT from a node-generated key. As long as the HIT can be allocated by >>> an enrollment server (or otherwise secured so that a single node >>> cannot generate multiple or arbitrary HITs), there isn't a security >>> problem here. If a node must be able to generate its own HIT, then >>> the HIT cannot be used as a replacement for the peer-id in a DHT. >> >> What prevents a node from allocating keys from the enrollment server until >> it gets what it wants? > > Yes, you need to throttle queries somewhat at the enrollment server. > But this is a much easier problem than throttling key generations > which don't require a server query. I have two questions regarding to this: * Is it possible to have a distributed enrollment server (i.e. the DHT) or is this an open research problem? * Why can't we just use a centralized enrollment server to distribute mandatory certificates for Host Identities? The enrollment server could still throttle based on the IP address of the client, which I assume you we suggesting? I find it a little bit controversial that the P2P-SIP is supposed to distributed (DHT) and non-distributed (enrollment servers) at the same time. Who owns the centralized enrollment server and how do you prevent it to become a single point of failure for P2P-SIP? -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 02:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2iWc-0001qL-TF; Thu, 13 Dec 2007 02:30:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2iWb-0001iO-BG for p2psip@ietf.org; Thu, 13 Dec 2007 02:30:29 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2iWa-0002g5-Im for p2psip@ietf.org; Thu, 13 Dec 2007 02:30:29 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D2E392E1D; Thu, 13 Dec 2007 09:30:27 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id BB3F62DF6; Thu, 13 Dec 2007 09:30:20 +0200 (EET) Date: Thu, 13 Dec 2007 09:30:20 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Bruce Lowekamp Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Wed, 12 Dec 2007, Bruce Lowekamp wrote: Hi, > On Dec 12, 2007 6:11 AM, Miika Komu wrote: >> On Mon, 10 Dec 2007, Bruce Lowekamp wrote: > >>>>> And the main problem with HIP might be: >>>>> >>>>> - resolving a HIT to an IP address is actually a very similar problem as >>>>> resolving a SIP URI to a Contact URI. And for HIP, this can be done by >>>>> adding some infrastructure, like rendez-points, registrations >>>>> extensions, DNS extensions, etc.. and *this HIP infrastructure is not >>>>> there yet!* >>>> >>>> Agree partially, but I think this would make new business cases for >>>> corporations from deploying infrastructure for customers. >>>> >>>> The DNS extensions are not mandatory. You can use opportunistic mode which >>>> works in the similar leap-of-fait manner as ssh. >>> >>> Surely there's an option in between "use dns" and "use leap-of-faith" >>> of using certificate chains? >> >> Surely, if you have PKI :) This has similar, or even worse, infrastructure >> requirements as DNS. > > Sorry, but I completely disagree here. An enrollment server > generating certificates requires one-time communication. The > enrollment server itself is trivial to write (ignoring how you > authenticate requesters, which will vary by the security model of the > overlay). It's a trivial addition that could even be provided with > every UA if desired for ad hoc environments. Agree if we are talking about a centralized enrollment server (which is not really PKI). >>> One of the confusing things about applying HIP to p2psip is the >>> layering issues required to address the deployment scenarios for >>> p2psip. We need it to work in an environment without provisioned DNS >>> support for the overlay and where we cannot assume an infrastructure >>> provider providing HIP relays. We need to be able to obtain those >>> services from peers in the overlay. So, minimally, this means the >>> ability to support the HIP relay functionality at the overlay layer. >>> This is where the proposal becomes confusing, because while HIP >>> provides a very nice abstraction on top of which to build a p2p >>> application, it also requires that p2p application for its >>> connectivity. >> >> By p2p application you mean the overlay? HIP provides security and NAT >> traversal for the overlay and the overlay does what it does. Not a bad >> casting of roles? > > Except that the overlay is still needed for rendezvous. Once you have > that, the nat traversal really isn't hard. What layer would you choose to implement the overlay and how would you deploy it? >>> HIP inside of a p2psip peer protocol, and I think it's entirely >>> doable, but I think we need to be clear on how the layering works and >>> what support is needed in both directions before deciding how to >>> accomplish it. >> >> This sounds like hi3 as long as we are talking about the overlay >> functionality: >> >> http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf >> http://www.tools.ietf.org/html/draft-nikander-hiprg-hi3-00 >> >> Certainly doable. At least OpenHIP and HIPL projects have implemented >> this. > > I'd be interested in how that's implemented. From what I can see, the > original papers simply assume the existence of Secure-i3 for > rendezvous, and I don't see detailed enough docs from OpenHIP or HIPL > for me to tell how they've implemented it. At least HIPL implements it by using the deployed i3 network in planetlab. If I recall correctly, HIP packets are transported over i3 headers through the overlay and ESP packets are sent directly between the peers. We are currently integrating STUN/ICE with "normal-mode" HIP and later with Hi3. The implementations are available at: http://infrahip.hiit.fi/ http://www.openhip.org/ http://www.hip4inter.net/ -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 03:17:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jGN-0002s3-1r; Thu, 13 Dec 2007 03:17:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jGL-0002rr-73 for p2psip@ietf.org; Thu, 13 Dec 2007 03:17:45 -0500 Received: from creon.otaverkko.fi ([212.68.0.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jGK-0001ko-A3 for p2psip@ietf.org; Thu, 13 Dec 2007 03:17:45 -0500 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 945257BC9D; Thu, 13 Dec 2007 10:17:43 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25000-04; Thu, 13 Dec 2007 10:17:36 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id F25C67BC48; Thu, 13 Dec 2007 10:17:35 +0200 (EET) Received: from ip91.infrahip.net (ip91.infrahip.net [193.167.187.91]) by argo.otaverkko.fi (Postfix) with ESMTP id ED3D425ED06; Thu, 13 Dec 2007 10:17:35 +0200 (EET) From: Joakim Koskela Organization: Helsinki Institute for Information Technology To: p2psip@ietf.org Subject: Re: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is appreciated. Date: Thu, 13 Dec 2007 10:17:38 +0200 User-Agent: KMail/1.9.7 References: <005f01c83d55$ccb927a0$5405a40a@china.huawei.com> In-Reply-To: <005f01c83d55$ccb927a0$5405a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712131017.38353.joakim.koskela@hiit.fi> X-Virus-Scanned: amavisd-new at otaverkko.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Maybe I missed something, but how were you planning to use the traceroute=20 packet? I mean, it will certainly tell you where the problem is and is good= =20 for debugging the network, but do you have plans for using the info somehow= =20 else (e.g. for somehow circumventing problem spots through source routing)? br ,j On Thursday 13 December 2007 09:00:09 Zheng Hewen wrote: > Hi, > > We extended our peer protocol (SEP: Service Extensible P2P Peer > Protocol, http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) = to > implement P2PSIP diagnosis > (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-diagnose-00.txt). > This document describes a simple and efficient mechanism that can be used > to detect and localize failures in P2PSIP overlay network. This document > mainly consists of two parts: information carried in a P2PSIP Peer "Echo > request" message and "Echo response" message for the purpose of fault > detection and localization, and mechanisms for processing those messages. > Any comment is appreciated. > > BTW, this I-D was finished before IETF70 as P2PSIP client protocol > (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-client-protocol-0= 0. >txt), they failed to be submitted due to mail server, we have to submit th= em > today through https://datatracker.ietf.org/idst/upload.cgi after only > changing creation date according to "IETF Internet-Draft Submission tool's > requirement". > > Best regards, > Hewen > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 2007=C4=EA12=D4=C213=C8=D5 14:33 > > To: hwzheng@huawei.com > > Cc: jiang.x.f@huawei.com > > Subject: New Version Notification for draft-zheng-p2psip-diagnose-00 > > > > > > A new version of I-D, draft-zheng-p2psip-diagnose-00.txt has > > been successfuly submitted by Hewen Zhang and posted to the > > IETF repository. > > > > Filename: draft-zheng-p2psip-diagnose > > Revision: 00 > > Title: Diagnose P2PSIP Overlay Network Failures > > Creation_date: 2007-12-11 > > WG ID: Independent Submission > > Number_of_pages: 21 > > > > Abstract: > > This document describes a simple and efficient mechanism that > > can be used to detect and localize failures in P2PSIP overlay > > network. This document mainly consists of two parts: > > information carried in a P2PSIP Peer "Echo request" message > > and "Echo response" message for the purpose of fault > > detection and localization, and mechanisms for processing > > those messages. > > > > > > > > > > The IETF Secretariat. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 04:56:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2kny-0001SJ-RT; Thu, 13 Dec 2007 04:56:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2knw-0001Rp-QH for p2psip@ietf.org; Thu, 13 Dec 2007 04:56:32 -0500 Received: from creon.otaverkko.fi ([212.68.0.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2knt-0006Pn-I3 for p2psip@ietf.org; Thu, 13 Dec 2007 04:56:30 -0500 Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id F11CD7BC86; Thu, 13 Dec 2007 11:56:27 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31144-09; Thu, 13 Dec 2007 11:56:12 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id A6B8F7BC62; Thu, 13 Dec 2007 11:56:11 +0200 (EET) Received: from ip91.infrahip.net (ip91.infrahip.net [193.167.187.91]) by argo.otaverkko.fi (Postfix) with ESMTP id E973525ED06; Thu, 13 Dec 2007 11:56:11 +0200 (EET) From: Joakim Koskela Organization: Helsinki Institute for Information Technology To: p2psip@ietf.org Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Thu, 13 Dec 2007 11:56:18 +0200 User-Agent: KMail/1.9.7 References: <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> In-Reply-To: <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712131156.18588.joakim.koskela@hiit.fi> X-Virus-Scanned: amavisd-new at otaverkko.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, I don't think there's anything in the with-hip that would prevent us from using opendht or any of the other proposed hip lookup infrastructures. My personal view on this thing is that when establishing p2p connections we should use all available methods/channels. One of the benefits of using hip is that we aren't bound to only using an ICE-like procedure through the overlay (which I think many of the proposals are restricted to), but we can also use whatever other methods that hip might provide - existing (dns, rvs, opendht ..), planned or something that hasn't even been thought of yet. Although will need the overlay for the initial aor lookup and it's usually a safe bet for getting initial packets through, I think it's also a good idea if we have some way of establishing connections in case the overlay gets partially congested or suitably populated with malicious / malfunctioning peers (which I guess can be a problem even if we have good access control and network diagnostics). That's why I'm voting for this sort of hybrid approach where we use hip for connections (thus benefit from existing non p2psip infrastructure), but where the bex can go through the overlay as well. The only thing that might be confusing is the layering issues. ..and to pour some fuel on that fire - is it really that bad sending the bex over the peer protocol? Doesn't actually most protocols relay their corresponding connection establishment info (ICE candidates) on top of the peer protocol? Would it help if we called it something like 'connectivity parameter packets' (instead of hip packets) which would just happen to have basically the same information as the I1/R1/I2/R2 packets (ICE candidates and keying material, signed) and be fed into the hip daemon on the receiver side? Is this just horribly wrong? Subsequent mobility / multihoming updates would of course be handled at the hip-layer only without any involvement of the p2psip application. br, j On Wednesday 12 December 2007 22:15:45 Philip Matthews wrote: > Henry: > > Though the below mentioned work on DHTs is similar to what P2PSIP is > looking at, none of the three proposals for using HIP for P2PSIP > published so far make use of it. > > - Philip > > On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > > Bruce, > > > >> We need it to work in an environment without provisioned DNS support > > > > for > > > >> the overlay and where we cannot assume an infrastructure provider > > > > providing >HIP relays. We need to be able to obtain those services > > from > > peers in the >overlay. So, minimally, this means the ability to > > support > > the HIP relay >functionality at the overlay layer. > > > > You are right. > > > > It appears this problem has been addressed in the I-D: > > draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) > > > > Jeff: Is this I-D still available online and do you intend to resubmit > > an update? > > > > Henry > > > > -----Original Message----- > > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > > Sent: Monday, December 10, 2007 10:57 AM > > To: Miika Komu > > Cc: p2psip@ietf.org > > Subject: Re: [P2PSIP] Re: HIP pros and cons > > > > On Dec 7, 2007 7:43 PM, Miika Komu wrote: > >> Ali Fessi wrote: > >>> - apparently, it has been currently understood that using the HIT as > > > > a > > > >>> peer-id is not a good idea. (due to chosen-location attacks, etc..). > > > > so > > > >>> what's the advantage for using HIP? > >> > >> I am not sure about the issue here but does the chosen-location > >> attack > >> have do anything with HIP? I think it is not really a HIP specific > > > > attack, > > > >> just something related to DHTs. > > > > The chosen location attack is related to the method of generating a > > HIT from a node-generated key. As long as the HIT can be allocated by > > an enrollment server (or otherwise secured so that a single node > > cannot generate multiple or arbitrary HITs), there isn't a security > > problem here. If a node must be able to generate its own HIT, then > > the HIT cannot be used as a replacement for the peer-id in a DHT. > > > >>> And the main problem with HIP might be: > >>> > >>> - resolving a HIT to an IP address is actually a very similar > > > > problem as > > > >>> resolving a SIP URI to a Contact URI. And for HIP, this can be done > > > > by > > > >>> adding some infrastructure, like rendez-points, registrations > >>> extensions, DNS extensions, etc.. and *this HIP infrastructure is > > > > not > > > >>> there yet!* > >> > >> Agree partially, but I think this would make new business cases for > >> corporations from deploying infrastructure for customers. > >> > >> The DNS extensions are not mandatory. You can use opportunistic mode > > > > which > > > >> works in the similar leap-of-fait manner as ssh. > > > > Surely there's an option in between "use dns" and "use leap-of-faith" > > of using certificate chains? > > > >>> - for NAT traversal: HIP is also doing ICE, which can be used for > > > > P2PSIP > > > >>> or any P2P application anyway. > >> > >> I'd disagree here. It is possible to use ICE in P2P-SIP because it is > >> completely new application and not a legacy application. However, if > > > > you > > > >> think about it architecturally, why makes P2P-SIP so special that it > > > > must > > > >> burden itself with NAT traversal? Why cannot just use a NAT traversal > >> service transparently from the lower layers? > >> > >> I think the designers and implementors of P2P-SIP can concentrate > > > > better > > > >> to some P2P-SIP issues if NAT traversal is handled by someone else. > >> > >>> If some people think that HIP is really a great idea for P2PSIP, > > > > then it > > > >>> should be also clear to the P2PSIP community what are all the > >>> consequences of using HIP, which additional infra do they need for > > > > using > > > >>> HIP, whether they need IPSec ESP support on each node, etc. > >> > >> Minimal requirements are that you need some HIP relays to transport > > > > the > > > >> HIP "offer/answer". Implementing NULL-ESP is trivial and supported by > > > > the > > > >> HIP specs. DNS extensions are not mandatory. > > > > (I rearranged this a little bit to bring these two issues together.) > > > > One of the confusing things about applying HIP to p2psip is the > > layering issues required to address the deployment scenarios for > > p2psip. We need it to work in an environment without provisioned DNS > > support for the overlay and where we cannot assume an infrastructure > > provider providing HIP relays. We need to be able to obtain those > > services from peers in the overlay. So, minimally, this means the > > ability to support the HIP relay functionality at the overlay layer. > > This is where the proposal becomes confusing, because while HIP > > provides a very nice abstraction on top of which to build a p2p > > application, it also requires that p2p application for its > > connectivity. > > > > I've spent some time working with Philip on how to provide support for > > HIP inside of a p2psip peer protocol, and I think it's entirely > > doable, but I think we need to be clear on how the layering works and > > what support is needed in both directions before deciding how to > > accomplish it. > > > > Bruce > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip -- Joakim Koskela Helsinki Institute for Information Technology (HIIT) email: joakim.koskela@hiit.fi mobile: +358 50 5459786 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 05:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2lI2-0001wM-GB; Thu, 13 Dec 2007 05:27:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2lI0-0001wG-SJ for p2psip@ietf.org; Thu, 13 Dec 2007 05:27:36 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2lHy-00064a-Kz for p2psip@ietf.org; Thu, 13 Dec 2007 05:27:36 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0A7BF2DF9; Thu, 13 Dec 2007 12:27:33 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D33412DF3; Thu, 13 Dec 2007 12:27:24 +0200 (EET) Date: Thu, 13 Dec 2007 12:27:24 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Ali Fessi Subject: Re: [P2PSIP] RE: HIP DHT interface (was HIP pros and cons) In-Reply-To: <47601019.6090103@uni-tuebingen.de> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <0DF156EE7414494187B087A3C279BDB4080C4EB1@XCH-NW-6V1.nw.nos.boeing.com> <47601019.6090103@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Henry Sinnreich , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Wed, 12 Dec 2007, Ali Fessi wrote: Hi Ali, the WG is currently chartered for NAT traversal. > Hi all, > > draft draft-ahrenholz-hiprg-dht is currenty an IRTF draft. > > Would it make sense to encourage the IETF HIP WG to work on this draft, since > it could be useful for the P2PSIP WG? > > > Cheers, > Ali > > Ahrenholz, Jeffrey M wrote: >> Henry, >> >>> It appears this problem has been addressed in the I-D: >>> draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) >>> >>> Jeff: Is this I-D still available online and do you intend to resubmit >>> an update? >>> >> >> Although this -01 draft has expired, yes I plan to submit a -02 update >> based on comments (see hipsec-rg mailing list from August 2007). Here is >> the expired draft: >> http://www.watersprings.org/pub/id/draft-ahrenholz-hiprg-dht-01.txt >> >> Also, we have deployed a DHT server on our HIP test server at >> hipserver.mct.phantomworks.org. When testing HIP you can use that server >> or the OpenDHT ring available on PlanetLab. The idea with having our own >> server is that in the future we may modify the Bamboo DHT code slightly >> to perform increased security checks (see the "hip-secure-addr" >> application from the draft.) >> >> -Jeff >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > -- > Ali Fessi > Computer Networks and Internet > University of Tuebingen, Germany > Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 > EMail: ali.fessi@uni-tuebingen.de > Web: http://net.informatik.uni-tuebingen.de/~fessi/ > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 06:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2mDC-0003VK-CB; Thu, 13 Dec 2007 06:26:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2mDA-0003VE-9P for p2psip@ietf.org; Thu, 13 Dec 2007 06:26:40 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2mD3-0000Zo-0W for p2psip@ietf.org; Thu, 13 Dec 2007 06:26:40 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00CJ4JQYVS@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 19:25:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00KTPJQXGE@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 19:25:46 +0800 (CST) Received: from z52048 ([10.164.5.84]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ00N16JQT4U@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 13 Dec 2007 19:25:45 +0800 (CST) Date: Thu, 13 Dec 2007 19:25:41 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is appreciated. In-reply-to: <200712131017.38353.joakim.koskela@hiit.fi> To: 'Joakim Koskela' , p2psip@ietf.org Message-id: <000901c83d7a$e5438110$5405a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: Acg9ZYwC2CjbJN9wQbyQvnwmjD21dAACEWuQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, You are right, this I-D only provides on-demand/periodic P2PSIP di= agnosis tool, and it does not describe how to use the=20 diagnosis result. Certainly, as said in "Security requirements in=20 P2PSIP"(http://tools.ietf.org/wg/p2psip/draft-matuszewski-p2psip-secu= rity-requirements-02.txt), "Req. 16: It SHOULD be=20 possible to limit the impact of badly behaving P2PSIP nodes on the ov= erall system security. There SHOULD be an option to=20 identify malfunctioning or badly behaving nodes, and exclude or rejec= t them from the P2PSIP system." This I-D provides tools to identify (i.e., detect and localize) ma= lfunctioning or badly behaving nodes, but how to exclude=20 or reject them from the P2PSIP system? Source routing is a good idea,= blacklisting is another idea. Essentially those are=20 already some implementations about how to use P2P diagnosis result in= open papers (there is an index in RFC4981). Currently we have no plan to describe how to use the info, but I = will be very interested in your plan if possible. Best regards, Hewen > -----Original Message----- > From: Joakim Koskela [mailto:joakim.koskela@hiit.fi] > Sent: 2007=C4=EA12=D4=C213=C8=D5 16:18 > To: p2psip@ietf.org > Cc: Zheng Hewen > Subject: Re: [P2PSIP] An I-D about P2PSIP diagnosis, any > comment is appreciated. > > Hi, > > Maybe I missed something, but how were you planning to use > the traceroute packet? I mean, it will certainly tell you > where the problem is and is good for debugging the network, > but do you have plans for using the info somehow else (e.g. > for somehow circumventing problem spots through source routing)? > > br ,j > > On Thursday 13 December 2007 09:00:09 Zheng Hewen wrote: > > Hi, > > > > We extended our peer protocol (SEP: Service Extensible P2P Pe= er > > Protocol, > > http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) to > > implement P2PSIP diagnosis > (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-diagno > se-00.txt). > > This document describes a simple and efficient mechanism > that can be > > used to detect and localize failures in P2PSIP overlay > network. This > > document mainly consists of two parts: information carried > in a P2PSIP > > Peer "Echo request" message and "Echo response" message for the > > purpose of fault detection and localization, and mechanisms > for processing those messages. > > Any comment is appreciated. > > > > BTW, this I-D was finished before IETF70 as P2PSIP > client protocol > >(http://www.ietf.org/internet-drafts/draft-zheng-p2psip-clien > t-protocol-00. > >txt), they failed to be submitted due to mail server, we > have to submit > >them today through > https://datatracker.ietf.org/idst/upload.cgi after > >only changing creation date according to "IETF Internet-Draft > >Submission tool's requirement". > > > > Best regards, > > Hewen > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: 20071213 14:33 > > > To: hwzheng@huawei.com > > > Cc: jiang.x.f@huawei.com > > > Subject: New Version Notification for > draft-zheng-p2psip-diagnose-00 > > > > > > > > > A new version of I-D, draft-zheng-p2psip-diagnose-00.txt has be= en > > > successfuly submitted by Hewen Zhang and posted to the IETF > > > repository. > > > > > > Filename:=09 draft-zheng-p2psip-diagnose > > > Revision:=09 00 > > > Title:=09=09 Diagnose P2PSIP Overlay Network Failures > > > Creation_date:=09 2007-12-11 > > > WG ID:=09=09 Independent Submission > > > Number_of_pages: 21 > > > > > > Abstract: > > > This document describes a simple and efficient mechanism > that can be > > > used to detect and localize failures in P2PSIP overlay network. > > > This document mainly consists of two parts: > > > information carried in a P2PSIP Peer "Echo request" message and > > > "Echo response" message for the purpose of fault detection and > > > localization, and mechanisms for processing those messages. > > > > > > > > > > > > > > > The IETF Secretariat. > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 08:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2o70-0007Da-Ny; Thu, 13 Dec 2007 08:28:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2o6z-0007DU-BK for p2psip@ietf.org; Thu, 13 Dec 2007 08:28:25 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2o6y-0003AL-HY for p2psip@ietf.org; Thu, 13 Dec 2007 08:28:25 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J2o6v-0007Sx-0r; Thu, 13 Dec 2007 08:28:21 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Thu, 13 Dec 2007 08:28:19 -0500 To: "Henry Sinnreich" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think it would be great to find synergies between all the efforts. This effort is starting now on the HIP RG mailing list. - Philip On 12-Dec-07, at 17:09 , Henry Sinnreich wrote: > Phil, > >> none of the three proposals for using HIP for P2PSIP >> published so far make use of it. > > Shouldn't we look at synergies between the _four_ efforts? > Maybe some separate session would be worth while. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, December 12, 2007 2:16 PM > To: Henry Sinnreich > Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; > p2psip@ietf.org > Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) > > Henry: > > Though the below mentioned work on DHTs is similar to what P2PSIP is > looking at, none of the three proposals for using HIP for P2PSIP > published so far make use of it. > > - Philip > > On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > >> Bruce, >> >>> We need it to work in an environment without provisioned DNS support >> for >>> the overlay and where we cannot assume an infrastructure provider >> providing >HIP relays. We need to be able to obtain those services >> from >> peers in the >overlay. So, minimally, this means the ability to >> support >> the HIP relay >functionality at the overlay layer. >> >> You are right. >> >> It appears this problem has been addressed in the I-D: >> draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) >> >> Jeff: Is this I-D still available online and do you intend to >> resubmit >> an update? >> >> Henry >> >> -----Original Message----- >> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] >> Sent: Monday, December 10, 2007 10:57 AM >> To: Miika Komu >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Re: HIP pros and cons >> >> On Dec 7, 2007 7:43 PM, Miika Komu wrote: >>> Ali Fessi wrote: >>>> - apparently, it has been currently understood that using the >>>> HIT as >> a >>>> peer-id is not a good idea. (due to chosen-location attacks, >>>> etc..). >> so >>>> what's the advantage for using HIP? >>> >>> I am not sure about the issue here but does the chosen-location >>> attack >>> have do anything with HIP? I think it is not really a HIP specific >> attack, >>> just something related to DHTs. >>> >> >> >> The chosen location attack is related to the method of generating a >> HIT from a node-generated key. As long as the HIT can be >> allocated by >> an enrollment server (or otherwise secured so that a single node >> cannot generate multiple or arbitrary HITs), there isn't a security >> problem here. If a node must be able to generate its own HIT, then >> the HIT cannot be used as a replacement for the peer-id in a DHT. >> >> >> >> >>>> And the main problem with HIP might be: >>>> >>>> - resolving a HIT to an IP address is actually a very similar >> problem as >>>> resolving a SIP URI to a Contact URI. And for HIP, this can be done >> by >>>> adding some infrastructure, like rendez-points, registrations >>>> extensions, DNS extensions, etc.. and *this HIP infrastructure is >> not >>>> there yet!* >>> >>> Agree partially, but I think this would make new business cases for >>> corporations from deploying infrastructure for customers. >>> >>> The DNS extensions are not mandatory. You can use opportunistic mode >> which >>> works in the similar leap-of-fait manner as ssh. >> >> Surely there's an option in between "use dns" and "use leap-of-faith" >> of using certificate chains? >> >> >> >>>> - for NAT traversal: HIP is also doing ICE, which can be used for >> P2PSIP >>>> or any P2P application anyway. >>> >>> I'd disagree here. It is possible to use ICE in P2P-SIP because >>> it is >>> completely new application and not a legacy application. However, if >> you >>> think about it architecturally, why makes P2P-SIP so special that it >> must >>> burden itself with NAT traversal? Why cannot just use a NAT >>> traversal >>> service transparently from the lower layers? >>> >>> I think the designers and implementors of P2P-SIP can concentrate >> better >>> to some P2P-SIP issues if NAT traversal is handled by someone else. >>> >>> >>>> If some people think that HIP is really a great idea for P2PSIP, >> then it >>>> should be also clear to the P2PSIP community what are all the >>>> consequences of using HIP, which additional infra do they need for >> using >>>> HIP, whether they need IPSec ESP support on each node, etc. >>> >>> Minimal requirements are that you need some HIP relays to transport >> the >>> HIP "offer/answer". Implementing NULL-ESP is trivial and >>> supported by >> the >>> HIP specs. DNS extensions are not mandatory. >>> >> >> (I rearranged this a little bit to bring these two issues together.) >> >> One of the confusing things about applying HIP to p2psip is the >> layering issues required to address the deployment scenarios for >> p2psip. We need it to work in an environment without provisioned DNS >> support for the overlay and where we cannot assume an infrastructure >> provider providing HIP relays. We need to be able to obtain those >> services from peers in the overlay. So, minimally, this means the >> ability to support the HIP relay functionality at the overlay layer. >> This is where the proposal becomes confusing, because while HIP >> provides a very nice abstraction on top of which to build a p2p >> application, it also requires that p2p application for its >> connectivity. >> >> I've spent some time working with Philip on how to provide support >> for >> HIP inside of a p2psip peer protocol, and I think it's entirely >> doable, but I think we need to be clear on how the layering works and >> what support is needed in both directions before deciding how to >> accomplish it. >> >> Bruce >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 10:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pqC-0007iy-Ok; Thu, 13 Dec 2007 10:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pqB-0007Xt-A2 for p2psip@ietf.org; Thu, 13 Dec 2007 10:19:11 -0500 Received: from exprod6og107.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2pqA-0006au-OI for p2psip@ietf.org; Thu, 13 Dec 2007 10:19:11 -0500 Received: from source ([192.150.20.142]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Thu, 13 Dec 2007 07:19:06 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBDFJ4nT019475; Thu, 13 Dec 2007 07:19:05 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBDFJ3RC002925; Thu, 13 Dec 2007 07:19:03 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 07:19:03 -0800 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 Subject: RE: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is appreciated. Date: Thu, 13 Dec 2007 07:19:02 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F4@namail5.corp.adobe.com> In-Reply-To: <005f01c83d55$ccb927a0$5405a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is appreciated. Thread-Index: Acg9UjN1tvQVMcSLSgqwZ546/JkO0AAArN3wABFbS4A= References: <005f01c83d55$ccb927a0$5405a40a@china.huawei.com> From: "Henry Sinnreich" To: "Zheng Hewen" , "P2PSIP Mailing List" X-OriginalArrivalTime: 13 Dec 2007 15:19:03.0588 (UTC) FILETIME=[7EC14640:01C83D9B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hewen, Can you share with us if this is only a concept paper or if you also = have tested the concept with running code? Thanks, Henry -----Original Message----- From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, December 13, 2007 1:00 AM To: 'P2PSIP Mailing List' Subject: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is = appreciated. Hi, We extended our peer protocol (SEP: Service Extensible P2P Peer = Protocol,=20 http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) to = implement P2PSIP diagnosis=20 (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-diagnose-00.txt).= This document describes a simple and efficient mechanism that can be = used to detect and localize failures in P2PSIP=20 overlay network. This document mainly consists of two parts: = information carried in a P2PSIP Peer "Echo request" message and=20 "Echo response" message for the purpose of fault detection and = localization, and mechanisms for processing those messages. Any comment is appreciated. BTW, this I-D was finished before IETF70 as P2PSIP client protocol=20 (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-client-protocol-0= 0.txt), they failed to be submitted due to mail=20 server, we have to submit them today through = https://datatracker.ietf.org/idst/upload.cgi after only changing = creation date=20 according to "IETF Internet-Draft Submission tool's requirement". Best regards, Hewen > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 2007=C4=EA12=D4=C213=C8=D5 14:33 > To: hwzheng@huawei.com > Cc: jiang.x.f@huawei.com > Subject: New Version Notification for draft-zheng-p2psip-diagnose-00 > > > A new version of I-D, draft-zheng-p2psip-diagnose-00.txt has > been successfuly submitted by Hewen Zhang and posted to the > IETF repository. > > Filename: draft-zheng-p2psip-diagnose > Revision: 00 > Title: Diagnose P2PSIP Overlay Network Failures > Creation_date: 2007-12-11 > WG ID: Independent Submission > Number_of_pages: 21 > > Abstract: > This document describes a simple and efficient mechanism that > can be used to detect and localize failures in P2PSIP overlay > network. This document mainly consists of two parts: > information carried in a P2PSIP Peer "Echo request" message > and "Echo response" message for the purpose of fault > detection and localization, and mechanisms for processing > those messages. > > > > > The IETF Secretariat. > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 10:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2prH-000207-1X; Thu, 13 Dec 2007 10:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2prE-000201-Sd for p2psip@ietf.org; Thu, 13 Dec 2007 10:20:16 -0500 Received: from exprod6og101.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2prD-0006cC-QP for p2psip@ietf.org; Thu, 13 Dec 2007 10:20:16 -0500 Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Thu, 13 Dec 2007 07:19:16 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBDFH012006729; Thu, 13 Dec 2007 07:17:01 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBDFJ6Fb023866; Thu, 13 Dec 2007 07:19:13 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 00:19:07 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Thu, 13 Dec 2007 07:18:58 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP DHT interface (was HIP pros and cons) Thread-Index: Acg9jA2UxIr8fe9xQi6UblLXEvts3AACzxWw References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 13 Dec 2007 15:19:07.0395 (UTC) FILETIME=[81062D30:01C83D9B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, > I think it would be great to find synergies between all the efforts. > This effort is starting now on the HIP RG mailing list. This is good news and I hope it will be pursued by all parties! What we need now is an _ANALYTICAL STUDY_ inside an I-D (instead of endless mail) showing what HIP is adding (or not) to P2PSIP and I hope the folks knowing HIP can collaborate for such a paper on a private list. For HIP supported NAT traversal, what are all the options to succeed in multi-NAT-ed networks, especially for hairpinning? Peers inside various NAT levels can use STUN techniques to determine their NAT scenario and communicate it to other peers, but such a protocol has net yet been proposed and ICE is really dealing best only with the NAT level closest to the STUN/TURN server. What could HIP do here better and if yes, then how?=20 Such 5%-10% corner cases where ICE may fail (are there other numbers?) but HIP may be more successful would indeed make all the difference. Or should we all admit that using port 80 (perish the thought) is the last resort for NAT traversal? If so, how does HIP matter? Again, a formal paper would really help. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Thursday, December 13, 2007 7:28 AM To: Henry Sinnreich Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; p2psip@ietf.org Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) I think it would be great to find synergies between all the efforts. This effort is starting now on the HIP RG mailing list. - Philip On 12-Dec-07, at 17:09 , Henry Sinnreich wrote: > Phil, > >> none of the three proposals for using HIP for P2PSIP >> published so far make use of it. > > Shouldn't we look at synergies between the _four_ efforts? > Maybe some separate session would be worth while. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, December 12, 2007 2:16 PM > To: Henry Sinnreich > Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; > p2psip@ietf.org > Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) > > Henry: > > Though the below mentioned work on DHTs is similar to what P2PSIP is > looking at, none of the three proposals for using HIP for P2PSIP > published so far make use of it. > > - Philip > > On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > >> Bruce, >> >>> We need it to work in an environment without provisioned DNS support >> for >>> the overlay and where we cannot assume an infrastructure provider >> providing >HIP relays. We need to be able to obtain those services >> from >> peers in the >overlay. So, minimally, this means the ability to >> support >> the HIP relay >functionality at the overlay layer. >> >> You are right. >> >> It appears this problem has been addressed in the I-D: >> draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) >> >> Jeff: Is this I-D still available online and do you intend to =20 >> resubmit >> an update? >> >> Henry >> >> -----Original Message----- >> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] >> Sent: Monday, December 10, 2007 10:57 AM >> To: Miika Komu >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Re: HIP pros and cons >> >> On Dec 7, 2007 7:43 PM, Miika Komu wrote: >>> Ali Fessi wrote: >>>> - apparently, it has been currently understood that using the =20 >>>> HIT as >> a >>>> peer-id is not a good idea. (due to chosen-location attacks, =20 >>>> etc..). >> so >>>> what's the advantage for using HIP? >>> >>> I am not sure about the issue here but does the chosen-location >>> attack >>> have do anything with HIP? I think it is not really a HIP specific >> attack, >>> just something related to DHTs. >>> >> >> >> The chosen location attack is related to the method of generating a >> HIT from a node-generated key. As long as the HIT can be =20 >> allocated by >> an enrollment server (or otherwise secured so that a single node >> cannot generate multiple or arbitrary HITs), there isn't a security >> problem here. If a node must be able to generate its own HIT, then >> the HIT cannot be used as a replacement for the peer-id in a DHT. >> >> >> >> >>>> And the main problem with HIP might be: >>>> >>>> - resolving a HIT to an IP address is actually a very similar >> problem as >>>> resolving a SIP URI to a Contact URI. And for HIP, this can be done >> by >>>> adding some infrastructure, like rendez-points, registrations >>>> extensions, DNS extensions, etc.. and *this HIP infrastructure is >> not >>>> there yet!* >>> >>> Agree partially, but I think this would make new business cases for >>> corporations from deploying infrastructure for customers. >>> >>> The DNS extensions are not mandatory. You can use opportunistic mode >> which >>> works in the similar leap-of-fait manner as ssh. >> >> Surely there's an option in between "use dns" and "use leap-of-faith" >> of using certificate chains? >> >> >> >>>> - for NAT traversal: HIP is also doing ICE, which can be used for >> P2PSIP >>>> or any P2P application anyway. >>> >>> I'd disagree here. It is possible to use ICE in P2P-SIP because =20 >>> it is >>> completely new application and not a legacy application. However, if >> you >>> think about it architecturally, why makes P2P-SIP so special that it >> must >>> burden itself with NAT traversal? Why cannot just use a NAT =20 >>> traversal >>> service transparently from the lower layers? >>> >>> I think the designers and implementors of P2P-SIP can concentrate >> better >>> to some P2P-SIP issues if NAT traversal is handled by someone else. >>> >>> >>>> If some people think that HIP is really a great idea for P2PSIP, >> then it >>>> should be also clear to the P2PSIP community what are all the >>>> consequences of using HIP, which additional infra do they need for >> using >>>> HIP, whether they need IPSec ESP support on each node, etc. >>> >>> Minimal requirements are that you need some HIP relays to transport >> the >>> HIP "offer/answer". Implementing NULL-ESP is trivial and =20 >>> supported by >> the >>> HIP specs. DNS extensions are not mandatory. >>> >> >> (I rearranged this a little bit to bring these two issues together.) >> >> One of the confusing things about applying HIP to p2psip is the >> layering issues required to address the deployment scenarios for >> p2psip. We need it to work in an environment without provisioned DNS >> support for the overlay and where we cannot assume an infrastructure >> provider providing HIP relays. We need to be able to obtain those >> services from peers in the overlay. So, minimally, this means the >> ability to support the HIP relay functionality at the overlay layer. >> This is where the proposal becomes confusing, because while HIP >> provides a very nice abstraction on top of which to build a p2p >> application, it also requires that p2p application for its >> connectivity. >> >> I've spent some time working with Philip on how to provide support =20 >> for >> HIP inside of a p2psip peer protocol, and I think it's entirely >> doable, but I think we need to be clear on how the layering works and >> what support is needed in both directions before deciding how to >> accomplish it. >> >> Bruce >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 11:14:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qi0-0003sb-33; Thu, 13 Dec 2007 11:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qhy-0003sJ-Ia for p2psip@ietf.org; Thu, 13 Dec 2007 11:14:46 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qhy-00082g-7w for p2psip@ietf.org; Thu, 13 Dec 2007 11:14:46 -0500 Received: by nz-out-0506.google.com with SMTP id n1so400350nzf.4 for ; Thu, 13 Dec 2007 08:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=fPwvlpWprqRMvvYDfLbAcY0ieYSp8/y3mvMdYekl8jc=; b=MWXobIHmXH17D/zTpNOzM+V6SGZ4RiGHO5SaiaDaaZrN10x9wQ9WDu6ZQ8yBjGbdK0t1L4AIm/MNFPXhtSECiSWh3KTShCad9zC6EfCn3pq9oEYbSDfSleZotL8Z9Q5KwYbS0rOWyP7tzKm6UWYvhIN80fZp1yZPLaLhy5EZ9xE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=h6cbsAvFn6QYS1Pou1F3re5EPrZoFDpfpQyCyOLnXK6U4hq8jV7JjkoMxLrnguBvE5bOE4rVjQxF8YeD6igTJWNgDK4qmBd/sWnMjbzbN3H8IwFBoYArjCf1P2bTYB44aOnIumlhJMg1gX+pdP3HetRmLyDvZMlhGsUvvq+1xqQ= Received: by 10.142.101.17 with SMTP id y17mr903423wfb.54.1197562483467; Thu, 13 Dec 2007 08:14:43 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 13 Dec 2007 08:14:43 -0800 (PST) Message-ID: <20d2bdfb0712130814l70efa822l1f30d0b3db049eb4@mail.gmail.com> Date: Thu, 13 Dec 2007 11:14:43 -0500 From: "Bruce Lowekamp" To: "Miika Komu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> X-Google-Sender-Auth: fbdbfc78e07e47e9 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 13, 2007 2:29 AM, Miika Komu wrote: > On Wed, 12 Dec 2007, Eric Rescorla wrote: > > > > Yes, you need to throttle queries somewhat at the enrollment server. > > But this is a much easier problem than throttling key generations > > which don't require a server query. > > I have two questions regarding to this: > * Is it possible to have a distributed enrollment server (i.e. the DHT) or > is this an open research problem? For the purposes of the p2psip wg, it was ruled out of scope as an open research problem. > * Why can't we just use a centralized enrollment server to distribute > mandatory certificates for Host Identities? The enrollment server could > still throttle based on the IP address of the client, which I assume you > we suggesting? As long as the enrollment server is able to restrict someone from picking arbitrary IDs and either throttles requests or restricts requests in some other way, that probably meets the security requirement. Not very secure if it's just based on the IP address of the client, though, as it's easy to get a lot of those. > I find it a little bit controversial that the P2P-SIP is supposed to > distributed (DHT) and non-distributed (enrollment servers) at the same > time. Who owns the centralized enrollment server and how do you prevent > it to become a single point of failure for P2P-SIP? > Depends on the deployment scenario. For a partial list, take a look at http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 11:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2r2Z-0003Wa-Sg; Thu, 13 Dec 2007 11:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2r2Y-0003Rv-L2 for p2psip@ietf.org; Thu, 13 Dec 2007 11:36:02 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2r2Y-0000oB-4d for p2psip@ietf.org; Thu, 13 Dec 2007 11:36:02 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6EE1433C72; Thu, 13 Dec 2007 08:30:33 -0800 (PST) Date: Thu, 13 Dec 2007 08:30:32 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071213163033.6EE1433C72@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Thu, 13 Dec 2007 09:29:37 +0200 (EET), Miika Komu wrote: > > On Wed, 12 Dec 2007, Eric Rescorla wrote: > > Hi Eric, > > > At Wed, 12 Dec 2007 13:11:45 +0200 (EET), > > Miika Komu wrote: > >> > >> On Mon, 10 Dec 2007, Bruce Lowekamp wrote: > >> > >>> On Dec 7, 2007 7:43 PM, Miika Komu wrote: > >>>> Ali Fessi wrote: > >>>>> - apparently, it has been currently understood that using the HIT as a > >>>>> peer-id is not a good idea. (due to chosen-location attacks, etc..). so > >>>>> what's the advantage for using HIP? > >>>> > >>>> I am not sure about the issue here but does the chosen-location attack > >>>> have do anything with HIP? I think it is not really a HIP specific attack, > >>>> just something related to DHTs. > >>> > >>> The chosen location attack is related to the method of generating a > >>> HIT from a node-generated key. As long as the HIT can be allocated by > >>> an enrollment server (or otherwise secured so that a single node > >>> cannot generate multiple or arbitrary HITs), there isn't a security > >>> problem here. If a node must be able to generate its own HIT, then > >>> the HIT cannot be used as a replacement for the peer-id in a DHT. > >> > >> What prevents a node from allocating keys from the enrollment server until > >> it gets what it wants? > > > > Yes, you need to throttle queries somewhat at the enrollment server. > > But this is a much easier problem than throttling key generations > > which don't require a server query. > > I have two questions regarding to this: > * Is it possible to have a distributed enrollment server (i.e. the DHT) or > is this an open research problem? It's an open research problem. Moreover it's explicitly a non-charter item. > * Why can't we just use a centralized enrollment server to distribute > mandatory certificates for Host Identities? The enrollment server could > still throttle based on the IP address of the client, which I assume you > we suggesting? I don't know what this means. The entire point of the HIP public-key->HIT relationship was to make HITs self-authenticating. Once you're using certificates, you've dramatically changed the situation. > I find it a little bit controversial that the P2P-SIP is supposed to > distributed (DHT) and non-distributed (enrollment servers) at the same > time. Well, again, it's a charter item, moreover, there was consensus *again* in YVR. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 12:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rQP-0002zD-WC; Thu, 13 Dec 2007 12:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rQO-0002z6-9y for p2psip@ietf.org; Thu, 13 Dec 2007 12:00:40 -0500 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rQN-0001Wf-LR for p2psip@ietf.org; Thu, 13 Dec 2007 12:00:40 -0500 Received: by wr-out-0506.google.com with SMTP id 68so445301wra.13 for ; Thu, 13 Dec 2007 09:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=J+ZbMGFZXB8PcxXmtaYz2kJw7HPiRYF4Pj2dm6mM1hQ=; b=ZsG0fsp2Ne9+mSDyIbTUGm0+pHUFeNzTS6Oc/UzGfe0TbJ/vhsvYCt47hQTOuBN/kO2U5ZzqqCJFk+zKqtdI99pqw780NLoRJhmERlgkHaWDW3AKWeFg97eUqQmmW7p87CqTroy7Z6jW/PprzmmSECcjdeZFYbs4qF6R2tC/Obs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Z+QkyfGHBsx238aoT8bsvNbdyK1dOD60DfxxIUPaa60JkChp/DoSx4Cxt6EfyaLa3rs5G4SzYTLxLL6FcFJVhwOhyRFE4GgaC6EK8mq5+8QGg2hvuXdswKEUSz2moU7tg60OM4vGAgy1WgRmH9t9vv8adfE3bAOfaqHIhcHJ70w= Received: by 10.142.77.11 with SMTP id z11mr947051wfa.98.1197565219115; Thu, 13 Dec 2007 09:00:19 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 13 Dec 2007 09:00:19 -0800 (PST) Message-ID: <20d2bdfb0712130900m17cbf61qbe3253be89768834@mail.gmail.com> Date: Thu, 13 Dec 2007 12:00:19 -0500 From: "Bruce Lowekamp" To: "Miika Komu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> X-Google-Sender-Auth: b3125071d8dcb97e X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 13, 2007 2:30 AM, Miika Komu wrote: > On Wed, 12 Dec 2007, Bruce Lowekamp wrote: > > On Dec 12, 2007 6:11 AM, Miika Komu wrote: > >>>> works in the similar leap-of-fait manner as ssh. > >>> > >>> Surely there's an option in between "use dns" and "use leap-of-faith" > >>> of using certificate chains? > >> > >> Surely, if you have PKI :) This has similar, or even worse, infrastructure > >> requirements as DNS. > > > > Sorry, but I completely disagree here. An enrollment server > > generating certificates requires one-time communication. The > > enrollment server itself is trivial to write (ignoring how you > > authenticate requesters, which will vary by the security model of the > > overlay). It's a trivial addition that could even be provided with > > every UA if desired for ad hoc environments. > > Agree if we are talking about a centralized enrollment server (which is > not really PKI). True. I think some of the application scenarios call for true PKI, but I don't think anyone has proposed solving that problem as part of a standards draft at this point (the assumption being that if someone wants to use this for a large-scale type deployment, they can figure out how to do it). > > >>> One of the confusing things about applying HIP to p2psip is the > >>> layering issues required to address the deployment scenarios for > >>> p2psip. We need it to work in an environment without provisioned DNS > >>> support for the overlay and where we cannot assume an infrastructure > >>> provider providing HIP relays. We need to be able to obtain those > >>> services from peers in the overlay. So, minimally, this means the > >>> ability to support the HIP relay functionality at the overlay layer. > >>> This is where the proposal becomes confusing, because while HIP > >>> provides a very nice abstraction on top of which to build a p2p > >>> application, it also requires that p2p application for its > >>> connectivity. > >> > >> By p2p application you mean the overlay? HIP provides security and NAT > >> traversal for the overlay and the overlay does what it does. Not a bad > >> casting of roles? > > > > Except that the overlay is still needed for rendezvous. Once you have > > that, the nat traversal really isn't hard. > > What layer would you choose to implement the overlay and how would you > deploy it? There are so many different proposals for architecture that I think it's hard to answer that question. Thinking of reload only (architecture at http://www.p2psip.org/drafts/draft-bryan-p2psip-reload-02.html#anchor2) anything from a "pure HIP" replacing both the Transport Layer and STUN/ICE at the forwarding layer, if it's in a deployment where the necessary infrastructure is there for HIP to function; to just as a transport layer with the overlay routing the setup messages (acting as a rendezvous server); to something where the p2psip functions without hip and essentially provides the id/locator abstraction to the application layer have been proposed in various p2psip drafts. I suspect that ultimately, we will not and should not settle on a single solution, but there will be a couple different options for transports that are viable and make sense in different deployment scenarios. If HIP proves itself useful, it will naturally be adopted. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 12:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rSm-0005he-6z; Thu, 13 Dec 2007 12:03:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rSl-0005cn-3g for p2psip@ietf.org; Thu, 13 Dec 2007 12:03:07 -0500 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2rSk-0001ab-6P for p2psip@ietf.org; Thu, 13 Dec 2007 12:03:07 -0500 Received: by wr-out-0506.google.com with SMTP id 68so446257wra.13 for ; Thu, 13 Dec 2007 09:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=w10IZR1Sf4mSvzIcv2o6JOOZFGzr1gIRrqfE6tWoKs8=; b=b+kFRNz7Ba1dc8c0lq2BkDRJxf/GV3K+Uq3eMS3d4cvZ9kd/d3TFOLpCTRfwiiuPlaR7jT4HBkEsR62aq6Cw1WA9KCCRwDA82jOvq2Ni6W3xOSlXtRWkO7MINSHqajH7c0q/swm/Ka4ILXuToAyw8Cn1n324oRkgZyu5yJTUD8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=izmh2MFS8DU1hhywo3vjZita3B3ffQapBAPOsfzIs0Xy21H3asDZYKdjyg4aDy0SCQ7r622Y1yIqXLOiCtD8OW8XMwbcrXdeIoUs+1MJXJTbN9FD2oCrpLkKYZ25pwgLoDxjzVPlBdOqY4xaZC+LSuwRfpJUm508CeVhdjrHKQg= Received: by 10.142.178.13 with SMTP id a13mr953287wff.17.1197565384939; Thu, 13 Dec 2007 09:03:04 -0800 (PST) Received: by 10.142.132.18 with HTTP; Thu, 13 Dec 2007 09:03:04 -0800 (PST) Message-ID: <20d2bdfb0712130903p2e9f3a20wd0197339f5deda76@mail.gmail.com> Date: Thu, 13 Dec 2007 12:03:04 -0500 From: "Bruce Lowekamp" To: "Henry Sinnreich" Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> X-Google-Sender-Auth: 5440752ff2e85ee8 X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: p2psip@ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 13, 2007 10:18 AM, Henry Sinnreich wrote: > Phil, > > > I think it would be great to find synergies between all the efforts. > > This effort is starting now on the HIP RG mailing list. > > This is good news and I hope it will be pursued by all parties! > > What we need now is an _ANALYTICAL STUDY_ inside an I-D (instead of > endless mail) showing what HIP is adding (or not) to P2PSIP and I hope > the folks knowing HIP can collaborate for such a paper on a private > list. > > For HIP supported NAT traversal, what are all the options to succeed in > multi-NAT-ed networks, especially for hairpinning? > > Peers inside various NAT levels can use STUN techniques to determine > their NAT scenario and communicate it to other peers, but such a > protocol has net yet been proposed and ICE is really dealing best only > with the NAT level closest to the STUN/TURN server. What could HIP do > here better and if yes, then how? > > Such 5%-10% corner cases where ICE may fail (are there other numbers?) > but HIP may be more successful would indeed make all the difference. > HIP is using ICE for establishing connectivity. It has a couple different interesting methods for locating a rendezvous server, but ICE is still the basic proposal for seeing if you can get a direct connection (or fallback to a relay) between nodes, AFAIK. Bruce > Or should we all admit that using port 80 (perish the thought) is the > last resort for NAT traversal? If so, how does HIP matter? Again, a > formal paper would really help. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Thursday, December 13, 2007 7:28 AM > To: Henry Sinnreich > Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; > p2psip@ietf.org > Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) > > I think it would be great to find synergies between all the efforts. > This effort is starting now on the HIP RG mailing list. > > - Philip > > On 12-Dec-07, at 17:09 , Henry Sinnreich wrote: > > > Phil, > > > >> none of the three proposals for using HIP for P2PSIP > >> published so far make use of it. > > > > Shouldn't we look at synergies between the _four_ efforts? > > Maybe some separate session would be worth while. > > > > Henry > > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Wednesday, December 12, 2007 2:16 PM > > To: Henry Sinnreich > > Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; > > p2psip@ietf.org > > Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) > > > > Henry: > > > > Though the below mentioned work on DHTs is similar to what P2PSIP is > > looking at, none of the three proposals for using HIP for P2PSIP > > published so far make use of it. > > > > - Philip > > > > On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > > > >> Bruce, > >> > >>> We need it to work in an environment without provisioned DNS support > >> for > >>> the overlay and where we cannot assume an infrastructure provider > >> providing >HIP relays. We need to be able to obtain those services > >> from > >> peers in the >overlay. So, minimally, this means the ability to > >> support > >> the HIP relay >functionality at the overlay layer. > >> > >> You are right. > >> > >> It appears this problem has been addressed in the I-D: > >> draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) > >> > >> Jeff: Is this I-D still available online and do you intend to > >> resubmit > >> an update? > >> > >> Henry > >> > >> -----Original Message----- > >> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > >> Sent: Monday, December 10, 2007 10:57 AM > >> To: Miika Komu > >> Cc: p2psip@ietf.org > >> Subject: Re: [P2PSIP] Re: HIP pros and cons > >> > >> On Dec 7, 2007 7:43 PM, Miika Komu wrote: > >>> Ali Fessi wrote: > >>>> - apparently, it has been currently understood that using the > >>>> HIT as > >> a > >>>> peer-id is not a good idea. (due to chosen-location attacks, > >>>> etc..). > >> so > >>>> what's the advantage for using HIP? > >>> > >>> I am not sure about the issue here but does the chosen-location > >>> attack > >>> have do anything with HIP? I think it is not really a HIP specific > >> attack, > >>> just something related to DHTs. > >>> > >> > >> > >> The chosen location attack is related to the method of generating a > >> HIT from a node-generated key. As long as the HIT can be > >> allocated by > >> an enrollment server (or otherwise secured so that a single node > >> cannot generate multiple or arbitrary HITs), there isn't a security > >> problem here. If a node must be able to generate its own HIT, then > >> the HIT cannot be used as a replacement for the peer-id in a DHT. > >> > >> > >> > >> > >>>> And the main problem with HIP might be: > >>>> > >>>> - resolving a HIT to an IP address is actually a very similar > >> problem as > >>>> resolving a SIP URI to a Contact URI. And for HIP, this can be done > >> by > >>>> adding some infrastructure, like rendez-points, registrations > >>>> extensions, DNS extensions, etc.. and *this HIP infrastructure is > >> not > >>>> there yet!* > >>> > >>> Agree partially, but I think this would make new business cases for > >>> corporations from deploying infrastructure for customers. > >>> > >>> The DNS extensions are not mandatory. You can use opportunistic mode > >> which > >>> works in the similar leap-of-fait manner as ssh. > >> > >> Surely there's an option in between "use dns" and "use leap-of-faith" > >> of using certificate chains? > >> > >> > >> > >>>> - for NAT traversal: HIP is also doing ICE, which can be used for > >> P2PSIP > >>>> or any P2P application anyway. > >>> > >>> I'd disagree here. It is possible to use ICE in P2P-SIP because > >>> it is > >>> completely new application and not a legacy application. However, if > >> you > >>> think about it architecturally, why makes P2P-SIP so special that it > >> must > >>> burden itself with NAT traversal? Why cannot just use a NAT > >>> traversal > >>> service transparently from the lower layers? > >>> > >>> I think the designers and implementors of P2P-SIP can concentrate > >> better > >>> to some P2P-SIP issues if NAT traversal is handled by someone else. > >>> > >>> > >>>> If some people think that HIP is really a great idea for P2PSIP, > >> then it > >>>> should be also clear to the P2PSIP community what are all the > >>>> consequences of using HIP, which additional infra do they need for > >> using > >>>> HIP, whether they need IPSec ESP support on each node, etc. > >>> > >>> Minimal requirements are that you need some HIP relays to transport > >> the > >>> HIP "offer/answer". Implementing NULL-ESP is trivial and > >>> supported by > >> the > >>> HIP specs. DNS extensions are not mandatory. > >>> > >> > >> (I rearranged this a little bit to bring these two issues together.) > >> > >> One of the confusing things about applying HIP to p2psip is the > >> layering issues required to address the deployment scenarios for > >> p2psip. We need it to work in an environment without provisioned DNS > >> support for the overlay and where we cannot assume an infrastructure > >> provider providing HIP relays. We need to be able to obtain those > >> services from peers in the overlay. So, minimally, this means the > >> ability to support the HIP relay functionality at the overlay layer. > >> This is where the proposal becomes confusing, because while HIP > >> provides a very nice abstraction on top of which to build a p2p > >> application, it also requires that p2p application for its > >> connectivity. > >> > >> I've spent some time working with Philip on how to provide support > >> for > >> HIP inside of a p2psip peer protocol, and I think it's entirely > >> doable, but I think we need to be clear on how the layering works and > >> what support is needed in both directions before deciding how to > >> accomplish it. > >> > >> Bruce > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 15:51:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2v29-0007wx-L6; Thu, 13 Dec 2007 15:51:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2v28-0007wM-P6 for p2psip@ietf.org; Thu, 13 Dec 2007 15:51:52 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2v27-0001E4-5E for p2psip@ietf.org; Thu, 13 Dec 2007 15:51:52 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 3017D2D70; Thu, 13 Dec 2007 22:51:50 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5ECC82C9F; Thu, 13 Dec 2007 22:51:41 +0200 (EET) Date: Thu, 13 Dec 2007 22:51:41 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20071213163033.6EE1433C72@delta.rtfm.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Thu, 13 Dec 2007, Eric Rescorla wrote: Hi Eric, >> * Why can't we just use a centralized enrollment server to distribute >> mandatory certificates for Host Identities? The enrollment server could >> still throttle based on the IP address of the client, which I assume you >> we suggesting? > > I don't know what this means. The entire point of the HIP public-key->HIT > relationship was to make HITs self-authenticating. Once you're using > certificates, you've dramatically changed the situation. It means that the centralized enrollment server has to sign your public key, possibly along with some other data such as URI. When too many enrollments are coming from a single IP, the enrollment server just drops the enrollments. Without successful enrollment, you cannot be part of the overlay. The enrollment procedure could be folded nicely to a HIP base exchange with some registration parameters: http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt It is possible to do this, of course, at the upper layers. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 15:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2v8P-0006oE-MV; Thu, 13 Dec 2007 15:58:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2v8O-0006o6-2H for p2psip@ietf.org; Thu, 13 Dec 2007 15:58:20 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2v8N-0001YH-MT for p2psip@ietf.org; Thu, 13 Dec 2007 15:58:19 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 548E933C6D; Thu, 13 Dec 2007 12:52:51 -0800 (PST) Date: Thu, 13 Dec 2007 12:52:50 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071213205251.548E933C6D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Thu, 13 Dec 2007 22:51:41 +0200 (EET), Miika Komu wrote: > > On Thu, 13 Dec 2007, Eric Rescorla wrote: > > Hi Eric, > > >> * Why can't we just use a centralized enrollment server to distribute > >> mandatory certificates for Host Identities? The enrollment server could > >> still throttle based on the IP address of the client, which I assume you > >> we suggesting? > > > > I don't know what this means. The entire point of the HIP public-key->HIT > > relationship was to make HITs self-authenticating. Once you're using > > certificates, you've dramatically changed the situation. > > It means that the centralized enrollment server has to sign your public > key, possibly along with some other data such as URI. When too many > enrollments are coming from a single IP, the enrollment server just drops > the enrollments. Without successful enrollment, you cannot be part of the > overlay. > > The enrollment procedure could be folded nicely to a HIP base exchange > with some registration parameters: > > http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt > > It is possible to do this, of course, at the upper layers. Yes, but I don't see how HIP is offering any advantage here. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 18:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2x4M-0002T6-FD; Thu, 13 Dec 2007 18:02:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2x4L-0002RI-OE for p2psip@ietf.org; Thu, 13 Dec 2007 18:02:17 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2x4L-0004zg-6z for p2psip@ietf.org; Thu, 13 Dec 2007 18:02:17 -0500 X-IronPort-AV: E=Sophos;i="4.24,163,1196658000"; d="scan'208";a="91180818" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 13 Dec 2007 18:02:14 -0500 X-IronPort-AV: E=Sophos;i="4.24,163,1196658000"; d="scan'208";a="140955130" Received: from unknown (HELO 306181ANEX3.global.avaya.com) ([135.9.6.102]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Dec 2007 18:01:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Thu, 13 Dec 2007 16:01:33 -0700 Message-ID: <166476A2803C3B4994D744DFD57A942F66385F@306181ANEX3.global.avaya.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg9ygGhUkZ8kDecTJGLnzBRyYzPmAAEUF0w References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><20071212160813.3863033C6D@delta.rtfm.com><20071213163033.6EE1433C72@delta.rtfm.com> From: "Palanisamy, Kandasamy (Kandasamy)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org How will centralized enrollment dropping too many enrollments from a single IP restrict enrollments from a botnet? Won't each entity in the botnet be considered a separate peer? How does any of the protocols - HIP-based or reload - handle botnets? Does that threat need to be addressed? Is that not applicable for the P2P scenario? Kand -----Original Message----- From: Miika Komu [mailto:miika@iki.fi]=20 Sent: Thursday, December 13, 2007 12:52 PM To: Eric Rescorla Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons On Thu, 13 Dec 2007, Eric Rescorla wrote: Hi Eric, >> * Why can't we just use a centralized enrollment server to distribute >> mandatory certificates for Host Identities? The enrollment server could >> still throttle based on the IP address of the client, which I assume you >> we suggesting? > > I don't know what this means. The entire point of the HIP=20 > public-key->HIT relationship was to make HITs self-authenticating.=20 > Once you're using certificates, you've dramatically changed the situation. It means that the centralized enrollment server has to sign your public key, possibly along with some other data such as URI. When too many enrollments are coming from a single IP, the enrollment server just drops the enrollments. Without successful enrollment, you cannot be part of the overlay. The enrollment procedure could be folded nicely to a HIP base exchange with some registration parameters: http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt It is possible to do this, of course, at the upper layers. --=20 Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 18:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xl9-0002JU-O3; Thu, 13 Dec 2007 18:46:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xl9-0002JP-BR for p2psip@ietf.org; Thu, 13 Dec 2007 18:46:31 -0500 Received: from exprod6og101.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2xl8-0005og-Nq for p2psip@ietf.org; Thu, 13 Dec 2007 18:46:31 -0500 Received: from source ([192.150.20.142]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Thu, 13 Dec 2007 15:46:27 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBDNkCnT011421; Thu, 13 Dec 2007 15:46:17 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBDNkARC022673; Thu, 13 Dec 2007 15:46:11 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 08:46:09 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Thu, 13 Dec 2007 15:46:02 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F9@namail5.corp.adobe.com> In-Reply-To: <20071213163033.6EE1433C72@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg9pk6fxdeHINsIQ6S062l6MMNAhgAOu4Mg References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> From: "Henry Sinnreich" To: "Eric Rescorla" , "Miika Komu" X-OriginalArrivalTime: 13 Dec 2007 23:46:09.0307 (UTC) FILETIME=[55E58EB0:01C83DE2] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> I find it a little bit controversial that the P2P-SIP is supposed to=20 >> distributed (DHT) and non-distributed (enrollment servers) at the same=20 >> time. >Well, again, it's a charter item, moreover, there was consensus >*again* in YVR. The charter says=20 "The initial work will assume the existence of some enrollment process..." "Developing a non-centralized enrollment process is not in scope." Research type p2p topics are also excluded.=20 http://ietf.org/html.charters/p2psip-charter.html=20 Please help me understand. Henry -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Thursday, December 13, 2007 10:31 AM To: Miika Komu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons At Thu, 13 Dec 2007 09:29:37 +0200 (EET), Miika Komu wrote: >=20 > On Wed, 12 Dec 2007, Eric Rescorla wrote: >=20 > Hi Eric, >=20 > > At Wed, 12 Dec 2007 13:11:45 +0200 (EET), > > Miika Komu wrote: > >> > >> On Mon, 10 Dec 2007, Bruce Lowekamp wrote: > >> > >>> On Dec 7, 2007 7:43 PM, Miika Komu wrote: > >>>> Ali Fessi wrote: > >>>>> - apparently, it has been currently understood that using the HIT as a > >>>>> peer-id is not a good idea. (due to chosen-location attacks, etc..). so > >>>>> what's the advantage for using HIP? > >>>> > >>>> I am not sure about the issue here but does the chosen-location attack > >>>> have do anything with HIP? I think it is not really a HIP specific attack, > >>>> just something related to DHTs. > >>> > >>> The chosen location attack is related to the method of generating a > >>> HIT from a node-generated key. As long as the HIT can be allocated by > >>> an enrollment server (or otherwise secured so that a single node > >>> cannot generate multiple or arbitrary HITs), there isn't a security > >>> problem here. If a node must be able to generate its own HIT, then > >>> the HIT cannot be used as a replacement for the peer-id in a DHT. > >> > >> What prevents a node from allocating keys from the enrollment server until > >> it gets what it wants? > > > > Yes, you need to throttle queries somewhat at the enrollment server. > > But this is a much easier problem than throttling key generations > > which don't require a server query. >=20 > I have two questions regarding to this: > * Is it possible to have a distributed enrollment server (i.e. the DHT) or > is this an open research problem? It's an open research problem. Moreover it's explicitly a non-charter item. > * Why can't we just use a centralized enrollment server to distribute > mandatory certificates for Host Identities? The enrollment server could > still throttle based on the IP address of the client, which I assume you > we suggesting? I don't know what this means. The entire point of the HIP public-key->HIT relationship was to make HITs self-authenticating. Once you're using certificates, you've dramatically changed the situation. > I find it a little bit controversial that the P2P-SIP is supposed to=20 > distributed (DHT) and non-distributed (enrollment servers) at the same > time. Well, again, it's a charter item, moreover, there was consensus *again* in YVR. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 18:49:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xo5-0005mP-8q; Thu, 13 Dec 2007 18:49:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xo3-0005mK-Ts for p2psip@ietf.org; Thu, 13 Dec 2007 18:49:31 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2xo3-0005rN-Fm for p2psip@ietf.org; Thu, 13 Dec 2007 18:49:31 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9F99733C6D; Thu, 13 Dec 2007 15:44:02 -0800 (PST) Date: Thu, 13 Dec 2007 15:44:01 -0800 From: Eric Rescorla To: "Henry Sinnreich" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F9@namail5.corp.adobe.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F9@namail5.corp.adobe.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071213234402.9F99733C6D@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Thu, 13 Dec 2007 15:46:02 -0800, Henry Sinnreich wrote: > > >> I find it a little bit controversial that the P2P-SIP is supposed to > >> distributed (DHT) and non-distributed (enrollment servers) at the > same > >> time. > > >Well, again, it's a charter item, moreover, there was consensus > >*again* in YVR. > > The charter says > "The initial work will assume the existence of some enrollment > process..." > "Developing a non-centralized enrollment process is not in scope." > > Research type p2p topics are also excluded. > > http://ietf.org/html.charters/p2psip-charter.html > > Please help me understand. Well, what I was trying to say was that centralized enrollment was a charter item and distributed was not. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 18:51:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xq9-0007IO-CB; Thu, 13 Dec 2007 18:51:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xq8-0007IE-BG for p2psip@ietf.org; Thu, 13 Dec 2007 18:51:40 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2xq8-00061o-0X for p2psip@ietf.org; Thu, 13 Dec 2007 18:51:40 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id F297F33C6D; Thu, 13 Dec 2007 15:46:11 -0800 (PST) Date: Thu, 13 Dec 2007 15:46:11 -0800 From: Eric Rescorla To: "Palanisamy, Kandasamy (Kandasamy)" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <166476A2803C3B4994D744DFD57A942F66385F@306181ANEX3.global.avaya.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <166476A2803C3B4994D744DFD57A942F66385F@306181ANEX3.global.avaya.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071213234611.F297F33C6D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Thu, 13 Dec 2007 16:01:33 -0700, Palanisamy, Kandasamy (Kandasamy) wrote: > How will centralized enrollment dropping too many enrollments from a > single IP restrict > enrollments from a botnet? Won't each entity in the botnet be > considered a separate > peer? Yes, it's clear that if you use IP then botnets are a problem. That's why I didn't make IP a concrete proposal for enrollment limitation. Clearly, there are techniques which are not botnet susceptible (e.g., credit card #). In any case, this question is out of scope for the WG. We are simply to assume that some mechanism exists for the central enrollment server to use to throttle mass enrollment by attackers. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 13 20:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2zHc-0001rk-W1; Thu, 13 Dec 2007 20:24:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2zHc-0001my-75 for p2psip@ietf.org; Thu, 13 Dec 2007 20:24:08 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2zHZ-0007l7-Os for p2psip@ietf.org; Thu, 13 Dec 2007 20:24:08 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT0000JIMJ24R@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 14 Dec 2007 09:23:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT000HMZMJ1U5@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 14 Dec 2007 09:23:26 +0800 (CST) Received: from z52048 ([10.164.5.84]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JT000COXMIX8B@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 14 Dec 2007 09:23:25 +0800 (CST) Date: Fri, 14 Dec 2007 09:23:23 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] An I-D about P2PSIP diagnosis, any comment is appreciated. In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F4@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'P2PSIP Mailing List' Message-id: <003601c83def$ebb847e0$5405a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: Acg9UjN1tvQVMcSLSgqwZ546/JkO0AAArN3wABFbS4AAFUYRIA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We already implemented Peer protocol proposal (http://tools.ietf.o= rg/wg/p2psip/draft-jiang-p2psip-sep-00.txt) and Client protocol proposal (http://tools.ietf.org/wg/p2psip/draft-pascual-p2ps= ip-clients-00.txt) in our prototype system, we are implementing P2PSIP diagnosis proposal (http://tools.ietf.org/wg/p2ps= ip/draft-zheng-p2psip-diagnose-00.txt) in our prototype system, any comment is welcome. Thanks, Hewen > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: 2007?12?13? 23:19 > To: Zheng Hewen; P2PSIP Mailing List > Subject: RE: [P2PSIP] An I-D about P2PSIP diagnosis, any > comment is appreciated. > > Hewen, > > Can you share with us if this is only a concept paper or if > you also have tested the concept with running code? > > Thanks, Henry > > -----Original Message----- > From: Zheng Hewen [mailto:hwzheng@huawei.com] > Sent: Thursday, December 13, 2007 1:00 AM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] An I-D about P2PSIP diagnosis, any comment > is appreciated. > > Hi, > > We extended our peer protocol (SEP: Service Extensible > P2P Peer Protocol, > http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) > to implement P2PSIP diagnosis > (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-diagno > se-00.txt). > This document describes a simple and efficient mechanism > that can be used to detect and localize failures in P2PSIP > overlay network. This document mainly consists of two parts: > information carried in a P2PSIP Peer "Echo request" message > and "Echo response" message for the purpose of fault > detection and localization, and mechanisms for processing > those messages. > Any comment is appreciated. > > BTW, this I-D was finished before IETF70 as P2PSIP client > protocol > (http://www.ietf.org/internet-drafts/draft-zheng-p2psip-client > -protocol-00.txt), they failed to be submitted due to mail > server, we have to submit them today through > https://datatracker.ietf.org/idst/upload.cgi after only > changing creation date according to "IETF Internet-Draft > Submission tool's requirement". > > Best regards, > Hewen > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 2007=C4=EA12=D4=C213=C8=D5 14:33 > > To: hwzheng@huawei.com > > Cc: jiang.x.f@huawei.com > > Subject: New Version Notification for draft-zheng-p2psip-diagnose= -00 > > > > > > A new version of I-D, draft-zheng-p2psip-diagnose-00.txt has been > > successfuly submitted by Hewen Zhang and posted to the IETF > > repository. > > > > Filename:=09 draft-zheng-p2psip-diagnose > > Revision:=09 00 > > Title:=09=09 Diagnose P2PSIP Overlay Network Failures > > Creation_date:=09 2007-12-11 > > WG ID:=09=09 Independent Submission > > Number_of_pages: 21 > > > > Abstract: > > This document describes a simple and efficient mechanism > that can be > > used to detect and localize failures in P2PSIP overlay > network. This > > document mainly consists of two parts: > > information carried in a P2PSIP Peer "Echo request" message > and "Echo > > response" message for the purpose of fault detection and > localization, > > and mechanisms for processing those messages. > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 01:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34E8-0006U0-7V; Fri, 14 Dec 2007 01:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34E6-0006Tu-QM for p2psip@ietf.org; Fri, 14 Dec 2007 01:40:50 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J34E4-00054R-8p for p2psip@ietf.org; Fri, 14 Dec 2007 01:40:50 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AC61B2EE5; Fri, 14 Dec 2007 08:40:47 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 60DD82EE5; Fri, 14 Dec 2007 08:40:40 +0200 (EET) Date: Fri, 14 Dec 2007 08:40:40 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Henry Sinnreich Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: p2psip@ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Thu, 13 Dec 2007, Henry Sinnreich wrote: Hi Henry, > What we need now is an _ANALYTICAL STUDY_ inside an I-D (instead of > endless mail) showing what HIP is adding (or not) to P2PSIP and I hope > the folks knowing HIP can collaborate for such a paper on a private > list. Sure, just let us know when the list exists. > For HIP supported NAT traversal, what are all the options to succeed in > multi-NAT-ed networks, especially for hairpinning? HIP use ICE as its NAT traversal mechanism and hence has the same properties as ICE. Also, it has few extra advantage over plain ICE. First, there is no need to burden the application with the details (=API) of ICE. Second, the application can address other peers globally using the HITs. Hairpinning means that a host talks to another host behind the same NAT. As I mentioned, HIP uses ICE and ICE supports hairpinning. However, when ICE tries connectivity tests between all candidate pairs, it tries also connectivity tests between HITs. As far as I have understoon, this should mean effectively that the HIP software should try to send HIP directly over IP. Legacy NATs will certainly drop these packets and we can determine that there is definitely not any NAT between. > Peers inside various NAT levels can use STUN techniques to determine > their NAT scenario and communicate it to other peers, but such a > protocol has net yet been proposed and ICE is really dealing best only > with the NAT level closest to the STUN/TURN server. What could HIP do > here better and if yes, then how? I think ICE does not care about NAT scenarios. It just gets a bunch of addresses associated with the local host and then it tries to connect them peer addresses. Trying to determine a NAT scenario is prone to error and has been excluded from ICE design because it is too flaky. > Such 5%-10% corner cases where ICE may fail (are there other numbers?) > but HIP may be more successful would indeed make all the difference. I am curious to get a reference for these numbers? I mentioned on benefit of HIP above regarding to hairpinning. We have also been discussing if we can reuse HIP D-H keymaterial to provide some extra protection for the STUN/ICE messages. > Or should we all admit that using port 80 (perish the thought) is the > last resort for NAT traversal? If so, how does HIP matter? Again, a > formal paper would really help. The ESP packets are supposed to be run over UDP unless the hosts are behind the same NAT, in which case we can exclude the UDP encapsulation. Also DNS requests use UDP, so I think they should traverse firewalls relative well. Unfortunately, I don't have any statistics to reference. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 02:08:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34f1-0000rf-Dq; Fri, 14 Dec 2007 02:08:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34f0-0000rX-Nb for p2psip@ietf.org; Fri, 14 Dec 2007 02:08:38 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J34f0-0006Ch-9F for p2psip@ietf.org; Fri, 14 Dec 2007 02:08:38 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 67A6E2C6F; Fri, 14 Dec 2007 09:08:37 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 858FA2CDE; Fri, 14 Dec 2007 09:08:30 +0200 (EET) Date: Fri, 14 Dec 2007 09:08:30 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20071213205251.548E933C6D@delta.rtfm.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Thu, 13 Dec 2007, Eric Rescorla wrote: > At Thu, 13 Dec 2007 22:51:41 +0200 (EET), > Miika Komu wrote: >> >> On Thu, 13 Dec 2007, Eric Rescorla wrote: >> >> Hi Eric, >> >>>> * Why can't we just use a centralized enrollment server to distribute >>>> mandatory certificates for Host Identities? The enrollment server could >>>> still throttle based on the IP address of the client, which I assume you >>>> we suggesting? >>> >>> I don't know what this means. The entire point of the HIP public-key->HIT >>> relationship was to make HITs self-authenticating. Once you're using >>> certificates, you've dramatically changed the situation. >> >> It means that the centralized enrollment server has to sign your public >> key, possibly along with some other data such as URI. When too many >> enrollments are coming from a single IP, the enrollment server just drops >> the enrollments. Without successful enrollment, you cannot be part of the >> overlay. >> >> The enrollment procedure could be folded nicely to a HIP base exchange >> with some registration parameters: >> >> http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt >> >> It is possible to do this, of course, at the upper layers. > > Yes, but I don't see how HIP is offering any advantage here. Ok, let's forget about the certificates with HIP then. If the clients create their own public keys and the centralized enrollment server requires the client to provide a credit card number or captcha, I don't see what is the problem then? I don't really see why the enrollment server needs to create the identifiers in such a case. The cost of an attack is just too expensive. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 03:41:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J367H-0000j9-Ud; Fri, 14 Dec 2007 03:41:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J367H-0000ei-8S for p2psip@ietf.org; Fri, 14 Dec 2007 03:41:55 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J367G-0008B3-BC for p2psip@ietf.org; Fri, 14 Dec 2007 03:41:54 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 8062528A17; Fri, 14 Dec 2007 16:41:50 +0800 (CST) Message-ID: <002001c83e2d$29259b40$da07740a@dellwei> From: "Wei Gengyu" To: "Bruce Lowekamp" References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <000c01c83bf2$3aa1dd30$da07740a@dellwei> <20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Fri, 14 Dec 2007 16:41:37 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0298471590==" Errors-To: p2psip-bounces@ietf.org --===============0298471590== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 QnJ1Y2UsIA0KDQpXaGF0IEkgdW5kZXJzdG9vZCB0byB1c2UgSElQIGluIHNvbWUgcHJvcG9zYWxz IGlzIGZvciBnZW5lcmF0aW9uIGFuZC9vciByZXNvbHV0aW9uIG9mIFBlZXIgSUQuDQpCZWZvcmUg ZXN0YWJsaXNoaW5nIGEgY29ubmV0aW9uIGJld2VlbiBQZWVycywgdGhlIGludGlhdGl2ZSBwZWVy IHNob3VsZCByZXNvbHZlIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBkZXN0aW5hdGlvbiBwZWVyIGJ5 IFBlZXIgSUQuDQpXaXRoIG9yIHdpdGhvdXQgSElQIGluIGNvbnZlbnRpb25hbCBJbnRlcm5ldCwg d2UgZG8gaXQgYnkgRE5TIHNlcnZpY2VzLg0KDQpUaGUgd29ya2luZyBlbnZpcm9ubWVudCB0aGF0 IHlvdSBzdXBwb3NlZCBpcyB3aXRob3V0IEROUywgc28gSElQIHdpbGwgYmUgYSBkb2FibGUgZmFj aWxpdHkgb2YgcmVzb2x1dGlvbiBmb3IgUDJQU0lQIG92ZXJsYXkuDQoNCk15IGJhc2ljIGlkZWEg aXMgdGhhdCBlYWNoIFBlZXIgc2hvdWxkIGRvIHJlc29sdXRpb24gcmVseWluZyBvbiBzb21lIGNv bW1vbiBmYWNpbGl0aWVzL3NlcnZpY2VzIGluIHRoZSBJbnRlcm5ldCwgbm90IGRvIGl0IGJ5IGl0 c2VsZi4gDQpBcyBQMlBTSVAgaXMganVzdCBhIGZhY2lsaXR5IHRvIHN1cHBvcnQgU0lQLCAgdGhl IFBlZXIgSUQgcmVzb2x1dGlvbiBtZWNoYW5pc20gaXMgbm90IHNvbGUgZnVudGlvbiBvZiBQMlBT SVAgDQphbW9uZyBhcHBsaWNhdGlvbnMgYmFzZWQgb24gUDJQIHRlY2hub2xvZ3kgaW4gSW50ZXJu ZXQuIA0KUHJhYmFibHkgdGhlcmUgaXMgYW5vdGhlciByZXNvbHV0aW9uIG1lY2hhbmlzbSBpbiB0 aGUgSW50ZXJuZXQsIHN1Y2ggYXMgUDJQTlMgd2hlbiBETlMgaXMgbm90IHRoZXJlLiANCg0KU28s IEkgdGhpbmsgUGVlciBJRCByZXNvbHV0aW9uIGZ1bmN0aW9uIGlzIGFuIGV4dGVybmFsIGZhY2ls aXR5IGFkaGVyZWQgdG8gUDJQU0lQLA0KanVzdCBhcyBETlMgc2VydmljZSBpcyBhbiBleHRlcm5h bCBmYWNpbHRpeSBvZiBTSVAuIA0KDQpJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIG5vdGljZWQgd2hl biBkZWZpbmluZyBwZWVyIHByb3RvY29sLg0KDQpHZW5neXUNCg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSANCkZyb206ICJCcnVjZSBMb3dla2FtcCIgPGxvd2VrYW1wQHNpcGVlcmlvci5j b20+DQpUbzogIldlaSBHZW5neXUiIDx3ZWlnZW5neXVAdmlwLnNpbmEuY29tPg0KQ2M6IDxwMnBz aXBAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTMsIDIwMDcgNzowMCBBTQ0K U3ViamVjdDogUmU6IFtQMlBTSVBdIFJlOiBISVAgcHJvcyBhbmQgY29ucw0KDQoNCj4gR2VuZ3l1 LA0KPiANCj4gT24gRGVjIDExLCAyMDA3IDc6MzQgQU0sIFdlaSBHZW5neXUgPHdlaWdlbmd5dUB2 aXAuc2luYS5jb20+IHdyb3RlOg0KPj4gV2hlbiB5b3Ugc3VwcG9zZSB0aGF0IFAyUFNJUCBvdmVy bGF5IHdvcmtzIGluIGFuIGVudmlyb25tZW50IHdpdGhvdXQgcHJvdmlzaW9uZWQgRE5TIHN1cHBv cnQgZm9yIHRoZSBvdmVybGF5LA0KPj4geW91IGFsc28gc3VwcG9zZSB0aGVyZSBhcmUgbm90IG90 aGVyIGZhY2lsaXRpZXMsIHN1Y2ggYXMgUDJQTlMsIHRvIHN1cHBvcnQgZm9yIG1hcHBpbmcgaG9z dCBpZCB0byBJUCBhZGRyZXNzLg0KPj4gU28geW91IGNvbmNsdWRlIHRoYXQgeW91IG5lZWQgdG8g ZG8gbWFwcGluZyBhdCB0aGUgUDJQU0lQIG92ZXJsYXkuICBJbiB0aGlzIHNpdHVhdGlvbiBISVAg aXMgcmVxdWlyZWQuDQo+PiBEbyBJIHVuZGVyc3RhbmQgaXQgcmlnaHQ/DQo+Pg0KPiANCj4gSSdt IG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgUDJQTlMgdGhlcmUuICBJIHRoaW5rIGFsbCBvZiB0 aGUgcGVlcg0KPiBwcm90b2NvbCBwcm9wb3NhbHMgaGF2ZSB3YXlzIG9mIHNlYXJjaGluZyBpbiB0 aGUgb3ZlcmxheSBhbmQNCj4gZXN0YWJsaXNoaW5nIGEgY29ubmVjdGlvbiB3aXRoIGEgc3BlY2lm aWMgcGVlci4gIENlcnRhaW5seSByZWxvYWQNCj4gZG9lcy4gIEhJUCBpc24ndCBuZWVkZWQgdG8g c29sdmUgdGhhdCBwcm9ibGVtLg0KPiANCj4gQnJ1Y2UNCj4= --===============0298471590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0298471590==-- From p2psip-bounces@ietf.org Fri Dec 14 06:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J38ft-0001vW-Qi; Fri, 14 Dec 2007 06:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J38fs-0001t8-7P for p2psip@ietf.org; Fri, 14 Dec 2007 06:25:48 -0500 Received: from exprod6og103.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J38fp-0002MF-RB for p2psip@ietf.org; Fri, 14 Dec 2007 06:25:48 -0500 Received: from source ([192.150.20.142]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Dec 2007 03:25:34 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBEBPUnT006325; Fri, 14 Dec 2007 03:25:31 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBEBPTFV020934; Fri, 14 Dec 2007 03:25:29 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 03:25:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Fri, 14 Dec 2007 03:24:52 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3FA@namail5.corp.adobe.com> In-Reply-To: <20d2bdfb0712130903p2e9f3a20wd0197339f5deda76@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP DHT interface (was HIP pros and cons) Thread-Index: Acg9qgqELYIAbqTgTfyfTU2XW1wcJAAmMfUg References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> <20d2bdfb0712130903p2e9f3a20wd0197339f5deda76@mail.gmail.com> From: "Henry Sinnreich" To: "Bruce Lowekamp" X-OriginalArrivalTime: 14 Dec 2007 11:25:28.0864 (UTC) FILETIME=[07BDDA00:01C83E44] X-Spam-Score: -4.0 (----) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: p2psip@ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce, >HIP is using ICE for establishing connectivity. How do you see the handling of multi-NAT-ed scenarios and hairpinning?=20 How can we detect multi-homing, before one of the links has failed? Henry -----Original Message----- From: lowekamp@gmail.com [mailto:lowekamp@gmail.com] On Behalf Of Bruce Lowekamp Sent: Thursday, December 13, 2007 11:03 AM To: Henry Sinnreich Cc: Philip Matthews; Miika Komu; jeffrey.m.ahrenholz@boeing.com; p2psip@ietf.org Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) On Dec 13, 2007 10:18 AM, Henry Sinnreich wrote: > Phil, > > > I think it would be great to find synergies between all the efforts. > > This effort is starting now on the HIP RG mailing list. > > This is good news and I hope it will be pursued by all parties! > > What we need now is an _ANALYTICAL STUDY_ inside an I-D (instead of > endless mail) showing what HIP is adding (or not) to P2PSIP and I hope > the folks knowing HIP can collaborate for such a paper on a private > list. > > For HIP supported NAT traversal, what are all the options to succeed in > multi-NAT-ed networks, especially for hairpinning? > > Peers inside various NAT levels can use STUN techniques to determine > their NAT scenario and communicate it to other peers, but such a > protocol has net yet been proposed and ICE is really dealing best only > with the NAT level closest to the STUN/TURN server. What could HIP do > here better and if yes, then how? > > Such 5%-10% corner cases where ICE may fail (are there other numbers?) > but HIP may be more successful would indeed make all the difference. > HIP is using ICE for establishing connectivity. It has a couple different interesting methods for locating a rendezvous server, but ICE is still the basic proposal for seeing if you can get a direct connection (or fallback to a relay) between nodes, AFAIK. Bruce > Or should we all admit that using port 80 (perish the thought) is the > last resort for NAT traversal? If so, how does HIP matter? Again, a > formal paper would really help. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Thursday, December 13, 2007 7:28 AM > To: Henry Sinnreich > Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; > p2psip@ietf.org > Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) > > I think it would be great to find synergies between all the efforts. > This effort is starting now on the HIP RG mailing list. > > - Philip > > On 12-Dec-07, at 17:09 , Henry Sinnreich wrote: > > > Phil, > > > >> none of the three proposals for using HIP for P2PSIP > >> published so far make use of it. > > > > Shouldn't we look at synergies between the _four_ efforts? > > Maybe some separate session would be worth while. > > > > Henry > > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Wednesday, December 12, 2007 2:16 PM > > To: Henry Sinnreich > > Cc: Bruce Lowekamp; Miika Komu; jeffrey.m.ahrenholz@boeing.com; > > p2psip@ietf.org > > Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) > > > > Henry: > > > > Though the below mentioned work on DHTs is similar to what P2PSIP is > > looking at, none of the three proposals for using HIP for P2PSIP > > published so far make use of it. > > > > - Philip > > > > On 11-Dec-07, at 19:48 , Henry Sinnreich wrote: > > > >> Bruce, > >> > >>> We need it to work in an environment without provisioned DNS support > >> for > >>> the overlay and where we cannot assume an infrastructure provider > >> providing >HIP relays. We need to be able to obtain those services > >> from > >> peers in the >overlay. So, minimally, this means the ability to > >> support > >> the HIP relay >functionality at the overlay layer. > >> > >> You are right. > >> > >> It appears this problem has been addressed in the I-D: > >> draft-ahrenholz-hiprg-dht-01 By J. Ahrenholz (2/12/2007) > >> > >> Jeff: Is this I-D still available online and do you intend to > >> resubmit > >> an update? > >> > >> Henry > >> > >> -----Original Message----- > >> From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > >> Sent: Monday, December 10, 2007 10:57 AM > >> To: Miika Komu > >> Cc: p2psip@ietf.org > >> Subject: Re: [P2PSIP] Re: HIP pros and cons > >> > >> On Dec 7, 2007 7:43 PM, Miika Komu wrote: > >>> Ali Fessi wrote: > >>>> - apparently, it has been currently understood that using the > >>>> HIT as > >> a > >>>> peer-id is not a good idea. (due to chosen-location attacks, > >>>> etc..). > >> so > >>>> what's the advantage for using HIP? > >>> > >>> I am not sure about the issue here but does the chosen-location > >>> attack > >>> have do anything with HIP? I think it is not really a HIP specific > >> attack, > >>> just something related to DHTs. > >>> > >> > >> > >> The chosen location attack is related to the method of generating a > >> HIT from a node-generated key. As long as the HIT can be > >> allocated by > >> an enrollment server (or otherwise secured so that a single node > >> cannot generate multiple or arbitrary HITs), there isn't a security > >> problem here. If a node must be able to generate its own HIT, then > >> the HIT cannot be used as a replacement for the peer-id in a DHT. > >> > >> > >> > >> > >>>> And the main problem with HIP might be: > >>>> > >>>> - resolving a HIT to an IP address is actually a very similar > >> problem as > >>>> resolving a SIP URI to a Contact URI. And for HIP, this can be done > >> by > >>>> adding some infrastructure, like rendez-points, registrations > >>>> extensions, DNS extensions, etc.. and *this HIP infrastructure is > >> not > >>>> there yet!* > >>> > >>> Agree partially, but I think this would make new business cases for > >>> corporations from deploying infrastructure for customers. > >>> > >>> The DNS extensions are not mandatory. You can use opportunistic mode > >> which > >>> works in the similar leap-of-fait manner as ssh. > >> > >> Surely there's an option in between "use dns" and "use leap-of-faith" > >> of using certificate chains? > >> > >> > >> > >>>> - for NAT traversal: HIP is also doing ICE, which can be used for > >> P2PSIP > >>>> or any P2P application anyway. > >>> > >>> I'd disagree here. It is possible to use ICE in P2P-SIP because > >>> it is > >>> completely new application and not a legacy application. However, if > >> you > >>> think about it architecturally, why makes P2P-SIP so special that it > >> must > >>> burden itself with NAT traversal? Why cannot just use a NAT > >>> traversal > >>> service transparently from the lower layers? > >>> > >>> I think the designers and implementors of P2P-SIP can concentrate > >> better > >>> to some P2P-SIP issues if NAT traversal is handled by someone else. > >>> > >>> > >>>> If some people think that HIP is really a great idea for P2PSIP, > >> then it > >>>> should be also clear to the P2PSIP community what are all the > >>>> consequences of using HIP, which additional infra do they need for > >> using > >>>> HIP, whether they need IPSec ESP support on each node, etc. > >>> > >>> Minimal requirements are that you need some HIP relays to transport > >> the > >>> HIP "offer/answer". Implementing NULL-ESP is trivial and > >>> supported by > >> the > >>> HIP specs. DNS extensions are not mandatory. > >>> > >> > >> (I rearranged this a little bit to bring these two issues together.) > >> > >> One of the confusing things about applying HIP to p2psip is the > >> layering issues required to address the deployment scenarios for > >> p2psip. We need it to work in an environment without provisioned DNS > >> support for the overlay and where we cannot assume an infrastructure > >> provider providing HIP relays. We need to be able to obtain those > >> services from peers in the overlay. So, minimally, this means the > >> ability to support the HIP relay functionality at the overlay layer. > >> This is where the proposal becomes confusing, because while HIP > >> provides a very nice abstraction on top of which to build a p2p > >> application, it also requires that p2p application for its > >> connectivity. > >> > >> I've spent some time working with Philip on how to provide support > >> for > >> HIP inside of a p2psip peer protocol, and I think it's entirely > >> doable, but I think we need to be clear on how the layering works and > >> what support is needed in both directions before deciding how to > >> accomplish it. > >> > >> Bruce > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 09:28:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3BWS-0003Zf-5A; Fri, 14 Dec 2007 09:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3BWR-0003PM-67 for p2psip@ietf.org; Fri, 14 Dec 2007 09:28:15 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3BWQ-0006mV-KZ for p2psip@ietf.org; Fri, 14 Dec 2007 09:28:15 -0500 Received: by wa-out-1112.google.com with SMTP id k40so2334945wah.25 for ; Fri, 14 Dec 2007 06:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=BQ9djI5QXr4c2tBwKaCbbVOtn3psfzC5o6whJJLToxw=; b=Z28KEg2Ab5+8G/BYzxzVmHkDGJ3shkc1yIdUu+nZuG5AtSGpo65Bo3n/UkCIpSN/5TQmCdcbqVNx3yCwge99O7qg1SFvzLixm5Rmn2WW12Xgpoowet6uXCeTXCDjaXxxFceKF2zPDyAEfGTjXBBZtVk7T8Km4tUyq52WLnsPky8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bzbw38eS+0GBg2eETabgqnZ1fVci6/1uvmxHihe4qoqCCuPWZbRJwnIP2LWKwEpUK75RF3pac2TvxRCDD1i7lgZ7gJORMT54FUIyHHhRq8LAtbv6NdR8pBsKslpq5uXizKEfXLcr/gxggciku2hQ1xa09SnhwIX/qP9YtF7t0kE= Received: by 10.142.165.9 with SMTP id n9mr1470432wfe.93.1197642493977; Fri, 14 Dec 2007 06:28:13 -0800 (PST) Received: by 10.142.132.18 with HTTP; Fri, 14 Dec 2007 06:28:13 -0800 (PST) Message-ID: <20d2bdfb0712140628v31e83621mdcb3087ac36fa42f@mail.gmail.com> Date: Fri, 14 Dec 2007 09:28:13 -0500 From: "Bruce Lowekamp" To: "Wei Gengyu" Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <002001c83e2d$29259b40$da07740a@dellwei> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <000c01c83bf2$3aa1dd30$da07740a@dellwei> <20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> X-Google-Sender-Auth: 8a789c08ab833438 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Dec 14, 2007 3:41 AM, Wei Gengyu wrote: > Bruce, > > What I understood to use HIP in some proposals is for generation and/or resolution of Peer ID. > Before establishing a connetion beween Peers, the intiative peer should resolve the IP address of the destination peer by Peer ID. > With or without HIP in conventional Internet, we do it by DNS services. > > The working environment that you supposed is without DNS, so HIP will be a doable facility of resolution for P2PSIP overlay. > I think HIP is an option for a transport, but I'm still unclear on how it will be accomplished. My impression is still that HIP is not designed to work standalone, i.e. in an ad hoc network without access to external services. It will have to rely on the P2P overlay for the rendezvous functionality it gets from other external services. I am also concerned that it appears to be addressing a different set of security concerns than a P2P overlay has, and it is not immediately clear to me how those will be resolved. Some of the advantages of HIP can be achieved with other techniques, such as Philip's ID/Loc draft. > My basic idea is that each Peer should do resolution relying on some common facilities/services in the Internet, not do it by itself. > As P2PSIP is just a facility to support SIP, the Peer ID resolution mechanism is not sole funtion of P2PSIP > among applications based on P2P technology in Internet. > Prabably there is another resolution mechanism in the Internet, such as P2PNS when DNS is not there. > > So, I think Peer ID resolution function is an external facility adhered to P2PSIP, > just as DNS service is an external faciltiy of SIP. > > I think this should be noticed when defining peer protocol. I think all of the p2psip peer protocol proposals at this point separate a basic P2P overlay routing and resource storage abstraction from the P2PSIP application layer. Bruce > > Gengyu > > ----- Original Message ----- > From: "Bruce Lowekamp" > To: "Wei Gengyu" > Cc: > Sent: Thursday, December 13, 2007 7:00 AM > Subject: Re: [P2PSIP] Re: HIP pros and cons > > > > > Gengyu, > > > > On Dec 11, 2007 7:34 AM, Wei Gengyu wrote: > >> When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay, > >> you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address. > >> So you conclude that you need to do mapping at the P2PSIP overlay. In this situation HIP is required. > >> Do I understand it right? > >> > > > > I'm not sure what you mean by P2PNS there. I think all of the peer > > protocol proposals have ways of searching in the overlay and > > establishing a connection with a specific peer. Certainly reload > > does. HIP isn't needed to solve that problem. > > > > Bruce > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 09:28:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3BWK-0002Hh-UO; Fri, 14 Dec 2007 09:28:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3BWI-0001yM-LF for p2psip@ietf.org; Fri, 14 Dec 2007 09:28:06 -0500 Received: from exprod6og107.obsmtp.com ([64.18.1.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3BWI-0007TT-0v for p2psip@ietf.org; Fri, 14 Dec 2007 09:28:06 -0500 Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Dec 2007 06:27:59 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBEEPg12003936; Fri, 14 Dec 2007 06:25:43 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBEEQrFj000032; Fri, 14 Dec 2007 06:27:55 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 23:27:17 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Fri, 14 Dec 2007 06:25:07 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> In-Reply-To: <002001c83e2d$29259b40$da07740a@dellwei> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg+LTxk5V5caJ3ESk6ripN+BYwq6QALzZCA References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> From: "Henry Sinnreich" To: "Wei Gengyu" , "Bruce Lowekamp" X-OriginalArrivalTime: 14 Dec 2007 14:27:17.0819 (UTC) FILETIME=[6DFC48B0:01C83E5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >Peer ID resolution function is an external facility adhered to=20 >P2PSIP, just as DNS service is an external faciltiy of SIP.=20 >I think this should be noticed when defining peer protocol. I agree. Could something like this also be included in the Concepts I-D? As for the HIP pros and cons, such a resolution at the HIP RSV level would work for any other application level protocols as well.=20 Do you see any problems? Henry -----Original Message----- From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Friday, December 14, 2007 2:42 AM To: Bruce Lowekamp Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons Bruce,=20 What I understood to use HIP in some proposals is for generation and/or resolution of Peer ID. Before establishing a connetion beween Peers, the intiative peer should resolve the IP address of the destination peer by Peer ID. With or without HIP in conventional Internet, we do it by DNS services. The working environment that you supposed is without DNS, so HIP will be a doable facility of resolution for P2PSIP overlay. My basic idea is that each Peer should do resolution relying on some common facilities/services in the Internet, not do it by itself.=20 As P2PSIP is just a facility to support SIP, the Peer ID resolution mechanism is not sole funtion of P2PSIP=20 among applications based on P2P technology in Internet.=20 Prabably there is another resolution mechanism in the Internet, such as P2PNS when DNS is not there.=20 So, I think Peer ID resolution function is an external facility adhered to P2PSIP, just as DNS service is an external faciltiy of SIP.=20 I think this should be noticed when defining peer protocol. Gengyu ----- Original Message -----=20 From: "Bruce Lowekamp" To: "Wei Gengyu" Cc: Sent: Thursday, December 13, 2007 7:00 AM Subject: Re: [P2PSIP] Re: HIP pros and cons > Gengyu, >=20 > On Dec 11, 2007 7:34 AM, Wei Gengyu wrote: >> When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay, >> you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address. >> So you conclude that you need to do mapping at the P2PSIP overlay. In this situation HIP is required. >> Do I understand it right? >> >=20 > I'm not sure what you mean by P2PNS there. I think all of the peer > protocol proposals have ways of searching in the overlay and > establishing a connection with a specific peer. Certainly reload > does. HIP isn't needed to solve that problem. >=20 > Bruce > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 09:28:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3BWK-0002Hh-UO; Fri, 14 Dec 2007 09:28:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3BWI-0001yM-LF for p2psip@ietf.org; Fri, 14 Dec 2007 09:28:06 -0500 Received: from exprod6og107.obsmtp.com ([64.18.1.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3BWI-0007TT-0v for p2psip@ietf.org; Fri, 14 Dec 2007 09:28:06 -0500 Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Dec 2007 06:27:59 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBEEPg12003936; Fri, 14 Dec 2007 06:25:43 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBEEQrFj000032; Fri, 14 Dec 2007 06:27:55 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 23:27:17 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Fri, 14 Dec 2007 06:25:07 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> In-Reply-To: <002001c83e2d$29259b40$da07740a@dellwei> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg+LTxk5V5caJ3ESk6ripN+BYwq6QALzZCA References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> From: "Henry Sinnreich" To: "Wei Gengyu" , "Bruce Lowekamp" X-OriginalArrivalTime: 14 Dec 2007 14:27:17.0819 (UTC) FILETIME=[6DFC48B0:01C83E5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >Peer ID resolution function is an external facility adhered to=20 >P2PSIP, just as DNS service is an external faciltiy of SIP.=20 >I think this should be noticed when defining peer protocol. I agree. Could something like this also be included in the Concepts I-D? As for the HIP pros and cons, such a resolution at the HIP RSV level would work for any other application level protocols as well.=20 Do you see any problems? Henry -----Original Message----- From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Friday, December 14, 2007 2:42 AM To: Bruce Lowekamp Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons Bruce,=20 What I understood to use HIP in some proposals is for generation and/or resolution of Peer ID. Before establishing a connetion beween Peers, the intiative peer should resolve the IP address of the destination peer by Peer ID. With or without HIP in conventional Internet, we do it by DNS services. The working environment that you supposed is without DNS, so HIP will be a doable facility of resolution for P2PSIP overlay. My basic idea is that each Peer should do resolution relying on some common facilities/services in the Internet, not do it by itself.=20 As P2PSIP is just a facility to support SIP, the Peer ID resolution mechanism is not sole funtion of P2PSIP=20 among applications based on P2P technology in Internet.=20 Prabably there is another resolution mechanism in the Internet, such as P2PNS when DNS is not there.=20 So, I think Peer ID resolution function is an external facility adhered to P2PSIP, just as DNS service is an external faciltiy of SIP.=20 I think this should be noticed when defining peer protocol. Gengyu ----- Original Message -----=20 From: "Bruce Lowekamp" To: "Wei Gengyu" Cc: Sent: Thursday, December 13, 2007 7:00 AM Subject: Re: [P2PSIP] Re: HIP pros and cons > Gengyu, >=20 > On Dec 11, 2007 7:34 AM, Wei Gengyu wrote: >> When you suppose that P2PSIP overlay works in an environment without provisioned DNS support for the overlay, >> you also suppose there are not other facilities, such as P2PNS, to support for mapping host id to IP address. >> So you conclude that you need to do mapping at the P2PSIP overlay. In this situation HIP is required. >> Do I understand it right? >> >=20 > I'm not sure what you mean by P2PNS there. I think all of the peer > protocol proposals have ways of searching in the overlay and > establishing a connection with a specific peer. Certainly reload > does. HIP isn't needed to solve that problem. >=20 > Bruce > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 09:41:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Bj9-0001IL-Gb; Fri, 14 Dec 2007 09:41:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Bj8-0001IG-FQ for p2psip@ietf.org; Fri, 14 Dec 2007 09:41:22 -0500 Received: from exprod6og107.obsmtp.com ([64.18.1.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3Bj7-0007o4-PQ for p2psip@ietf.org; Fri, 14 Dec 2007 09:41:22 -0500 Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Dec 2007 06:41:17 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBEEd112005605; Fri, 14 Dec 2007 06:39:01 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBEEfDFV001139; Fri, 14 Dec 2007 06:41:14 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 23:41:12 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Fri, 14 Dec 2007 06:38:57 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE400@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP DHT interface (was HIP pros and cons) Thread-Index: Acg+HEWu0pw39VZhSru5iZE3WFc8+wAQdwFg References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "Miika Komu" X-OriginalArrivalTime: 14 Dec 2007 14:41:12.0814 (UTC) FILETIME=[5FAE68E0:01C83E5F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: p2psip@ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Miika, >> Such 5%-10% corner cases where ICE may fail (are there other numbers?) >> but HIP may be more successful would indeed make all the difference. >I am curious to get a reference for these numbers? http://www.bford.info/pub/net/p2pnat/ The numbers are actually far worse. Look at Table 1. I must confess this paper has made me more than cautious until we see similar tools and deployment measurements for ICE and ICE-based HIP NAT traversal. Not to mention delay measurements. Henry=20 -----Original Message----- From: Miika Komu [mailto:miika@iki.fi]=20 Sent: Friday, December 14, 2007 12:41 AM To: Henry Sinnreich Cc: Philip Matthews; Bruce Lowekamp; jeffrey.m.ahrenholz@boeing.com; p2psip@ietf.org Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) On Thu, 13 Dec 2007, Henry Sinnreich wrote: Hi Henry, > What we need now is an _ANALYTICAL STUDY_ inside an I-D (instead of > endless mail) showing what HIP is adding (or not) to P2PSIP and I hope > the folks knowing HIP can collaborate for such a paper on a private > list. Sure, just let us know when the list exists. > For HIP supported NAT traversal, what are all the options to succeed in > multi-NAT-ed networks, especially for hairpinning? HIP use ICE as its NAT traversal mechanism and hence has the same=20 properties as ICE. Also, it has few extra advantage over plain ICE. First,=20 there is no need to burden the application with the details (=3DAPI) of ICE.=20 Second, the application can address other peers globally using the HITs. Hairpinning means that a host talks to another host behind the same NAT. As I mentioned, HIP uses ICE and ICE supports hairpinning. However, when ICE tries connectivity tests between all candidate pairs, it tries also=20 connectivity tests between HITs. As far as I have understoon, this should=20 mean effectively that the HIP software should try to send HIP directly=20 over IP. Legacy NATs will certainly drop these packets and we can=20 determine that there is definitely not any NAT between. > Peers inside various NAT levels can use STUN techniques to determine > their NAT scenario and communicate it to other peers, but such a > protocol has net yet been proposed and ICE is really dealing best only > with the NAT level closest to the STUN/TURN server. What could HIP do > here better and if yes, then how? I think ICE does not care about NAT scenarios. It just gets a bunch of=20 addresses associated with the local host and then it tries to connect them=20 peer addresses. Trying to determine a NAT scenario is prone to error and has been excluded from ICE design because it is too flaky. > Such 5%-10% corner cases where ICE may fail (are there other numbers?) > but HIP may be more successful would indeed make all the difference. I am curious to get a reference for these numbers? I mentioned on benefit of HIP above regarding to hairpinning. We have also=20 been discussing if we can reuse HIP D-H keymaterial to provide some extra=20 protection for the STUN/ICE messages. > Or should we all admit that using port 80 (perish the thought) is the > last resort for NAT traversal? If so, how does HIP matter? Again, a > formal paper would really help. The ESP packets are supposed to be run over UDP unless the hosts are=20 behind the same NAT, in which case we can exclude the UDP encapsulation. Also DNS requests use UDP, so I think they should traverse firewalls=20 relative well. Unfortunately, I don't have any statistics to reference. --=20 Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 10:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3C4R-0000Ni-Tw; Fri, 14 Dec 2007 10:03:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3C4P-0000ND-KN for p2psip@ietf.org; Fri, 14 Dec 2007 10:03:21 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3C4P-0008GD-4R for p2psip@ietf.org; Fri, 14 Dec 2007 10:03:21 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E37DF33C6D; Fri, 14 Dec 2007 06:57:48 -0800 (PST) Date: Fri, 14 Dec 2007 06:57:48 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071214145748.E37DF33C6D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Fri, 14 Dec 2007 09:08:30 +0200 (EET), Miika Komu wrote: > > On Thu, 13 Dec 2007, Eric Rescorla wrote: > > > At Thu, 13 Dec 2007 22:51:41 +0200 (EET), > > Miika Komu wrote: > >> > >> On Thu, 13 Dec 2007, Eric Rescorla wrote: > >> > >> Hi Eric, > >> > >>>> * Why can't we just use a centralized enrollment server to distribute > >>>> mandatory certificates for Host Identities? The enrollment server could > >>>> still throttle based on the IP address of the client, which I assume you > >>>> we suggesting? > >>> > >>> I don't know what this means. The entire point of the HIP public-key->HIT > >>> relationship was to make HITs self-authenticating. Once you're using > >>> certificates, you've dramatically changed the situation. > >> > >> It means that the centralized enrollment server has to sign your public > >> key, possibly along with some other data such as URI. When too many > >> enrollments are coming from a single IP, the enrollment server just drops > >> the enrollments. Without successful enrollment, you cannot be part of the > >> overlay. > >> > >> The enrollment procedure could be folded nicely to a HIP base exchange > >> with some registration parameters: > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt > >> > >> It is possible to do this, of course, at the upper layers. > > > > Yes, but I don't see how HIP is offering any advantage here. > > Ok, let's forget about the certificates with HIP then. If the clients > create their own public keys and the centralized enrollment server > requires the client to provide a credit card number or captcha, I don't > see what is the problem then? Then how does a relying party verify that the client actually enrolled rather than just generated their own key and didn't enroll? > I don't really see why the enrollment server > needs to create the identifiers in such a case. The cost of an attack is > just too expensive. Huh? Attacking a single point on the overlay is the cost of doing a single captcha (about $.01). I'm sorry if this seems overly direct, but (1) this is a significant open research problem (2) I've gone over these issues a number of times on the list and in person and (3) this is out of our charter scope. If you think you've solved the distributed DHT enrollment problem, and you have a complete description of your proposed solution complete with security analysis, I'll be happy to read it, but I don't see a lot of point on going over the same ground repeatedly on the list. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 12:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EEb-0002Tj-Bp; Fri, 14 Dec 2007 12:22:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3EEZ-0002Gm-J7 for p2psip@ietf.org; Fri, 14 Dec 2007 12:21:59 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3EEW-0003eY-8x for p2psip@ietf.org; Fri, 14 Dec 2007 12:21:57 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 15EC51DE821; Sat, 15 Dec 2007 01:21:51 +0800 (CST) Message-ID: <000801c83e75$ce72b9a0$da07740a@dellwei> From: "Wei Gengyu" To: "Henry Sinnreich" , "Bruce Lowekamp" References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Sat, 15 Dec 2007 01:21:19 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0269283218==" Errors-To: p2psip-bounces@ietf.org --===============0269283218== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 VGhlcmUgaXMgb25lIHBvc3NpYmxlIHByb2JsZW0uDQoNCkhJUCBoYXMgYWxyZWFkeSBiZWVuIHN0 YW5kYXJkaXplZCBmb3IgSG9zZCBpbmRlbnRpZmljYXRpb24gaW4gcmZjNDQyMy4gDQpFYWNoIGhv c3Qgd291bGQgaGF2ZSBvbmx5IG9uZSBISVQgYWNjb3JkaW5nIHRvIFJGQzQ0MjMuDQpQZWVyIElE IGlzIGFuIGlkZW50aWZpZXIgb2YgUGVlciBlbnRpdHkgaW4gUDJQU0lQIG92ZXJsYXkgKGF0IGFw cGxpY2F0aW9uIGxheWVyIG9mIEludGVybmV0KS4NClRoZXJlIGlzIGEgcHJvcG9zYWwgb2YgdXNp bmcgSElUIGFzIFBlZXIgSUQsIHNvIGEgaG9zdCBjb3VsZCBvbmx5IGhhdmUgb25lIFBlZXIgZW50 aXR5Lg0KDQpCdXQsIGlmIHRoZXJlIGFyZSB0d28gb3IgbW9yZSBQZWVyIGVudGl0aWVzIGxvY2F0 ZWQgYXQgb25lIGhvc3QsIGhvdyBjb3VsZCB5b3UgbWFuYWdlIHRoZW0/DQpJbiBnZW5lcmFsLCBJ IHRoaW5rLCBpdCBpcyBwb3NzaWJsZSB0aGF0ICBtb3JlIHRoYW4gb25lIFBlZXIgZW50aXR5IGxv Y2F0ZWQgYXQgb25lIGhvc3QuICANCg0KSG93IGRvIHlvdSB0aGluayBvZiB0aGlzPw0KDQpHZW5n eXUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJIZW5yeSBTaW5ucmVp Y2giIDxoc2lubnJlaUBhZG9iZS5jb20+DQpUbzogIldlaSBHZW5neXUiIDx3ZWlnZW5neXVAdmlw LnNpbmEuY29tPjsgIkJydWNlIExvd2VrYW1wIiA8bG93ZWthbXBAc2lwZWVyaW9yLmNvbT4NCkNj OiA8cDJwc2lwQGlldGYub3JnPg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAwNyAxMDoy NSBQTQ0KU3ViamVjdDogUkU6IFtQMlBTSVBdIFJlOiBISVAgcHJvcyBhbmQgY29ucw0KDQoNCj5Q ZWVyIElEIHJlc29sdXRpb24gZnVuY3Rpb24gaXMgYW4gZXh0ZXJuYWwgZmFjaWxpdHkgYWRoZXJl ZCB0byANCj5QMlBTSVAsIGp1c3QgYXMgRE5TIHNlcnZpY2UgaXMgYW4gZXh0ZXJuYWwgZmFjaWx0 aXkgb2YgU0lQLiANCg0KPkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgbm90aWNlZCB3aGVuIGRlZmlu aW5nIHBlZXIgcHJvdG9jb2wuDQoNCkkgYWdyZWUuIENvdWxkIHNvbWV0aGluZyBsaWtlIHRoaXMg YWxzbyBiZSBpbmNsdWRlZCBpbiB0aGUgQ29uY2VwdHMgSS1EPw0KDQpBcyBmb3IgdGhlIEhJUCBw cm9zIGFuZCBjb25zLCBzdWNoIGEgcmVzb2x1dGlvbiBhdCB0aGUgSElQIFJTViBsZXZlbA0Kd291 bGQgd29yayBmb3IgYW55IG90aGVyIGFwcGxpY2F0aW9uIGxldmVsIHByb3RvY29scyBhcyB3ZWxs LiANCkRvIHlvdSBzZWUgYW55IHByb2JsZW1zPw0KDQpIZW5yeQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2VpIEdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUB2aXAuc2luYS5j b21dIA0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxNCwgMjAwNyAyOjQyIEFNDQpUbzogQnJ1Y2Ug TG93ZWthbXANCkNjOiBwMnBzaXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBSZTog SElQIHByb3MgYW5kIGNvbnMNCg0KQnJ1Y2UsIA0KDQpXaGF0IEkgdW5kZXJzdG9vZCB0byB1c2Ug SElQIGluIHNvbWUgcHJvcG9zYWxzIGlzIGZvciBnZW5lcmF0aW9uIGFuZC9vcg0KcmVzb2x1dGlv biBvZiBQZWVyIElELg0KQmVmb3JlIGVzdGFibGlzaGluZyBhIGNvbm5ldGlvbiBiZXdlZW4gUGVl cnMsIHRoZSBpbnRpYXRpdmUgcGVlciBzaG91bGQNCnJlc29sdmUgdGhlIElQIGFkZHJlc3Mgb2Yg dGhlIGRlc3RpbmF0aW9uIHBlZXIgYnkgUGVlciBJRC4NCldpdGggb3Igd2l0aG91dCBISVAgaW4g Y29udmVudGlvbmFsIEludGVybmV0LCB3ZSBkbyBpdCBieSBETlMgc2VydmljZXMuDQoNClRoZSB3 b3JraW5nIGVudmlyb25tZW50IHRoYXQgeW91IHN1cHBvc2VkIGlzIHdpdGhvdXQgRE5TLCBzbyBI SVAgd2lsbCBiZQ0KYSBkb2FibGUgZmFjaWxpdHkgb2YgcmVzb2x1dGlvbiBmb3IgUDJQU0lQIG92 ZXJsYXkuDQoNCk15IGJhc2ljIGlkZWEgaXMgdGhhdCBlYWNoIFBlZXIgc2hvdWxkIGRvIHJlc29s dXRpb24gcmVseWluZyBvbiBzb21lDQpjb21tb24gZmFjaWxpdGllcy9zZXJ2aWNlcyBpbiB0aGUg SW50ZXJuZXQsIG5vdCBkbyBpdCBieSBpdHNlbGYuIA0KQXMgUDJQU0lQIGlzIGp1c3QgYSBmYWNp bGl0eSB0byBzdXBwb3J0IFNJUCwgIHRoZSBQZWVyIElEIHJlc29sdXRpb24NCm1lY2hhbmlzbSBp cyBub3Qgc29sZSBmdW50aW9uIG9mIFAyUFNJUCANCmFtb25nIGFwcGxpY2F0aW9ucyBiYXNlZCBv biBQMlAgdGVjaG5vbG9neSBpbiBJbnRlcm5ldC4gDQpQcmFiYWJseSB0aGVyZSBpcyBhbm90aGVy IHJlc29sdXRpb24gbWVjaGFuaXNtIGluIHRoZSBJbnRlcm5ldCwgc3VjaCBhcw0KUDJQTlMgd2hl biBETlMgaXMgbm90IHRoZXJlLiANCg0KU28sIEkgdGhpbmsgUGVlciBJRCByZXNvbHV0aW9uIGZ1 bmN0aW9uIGlzIGFuIGV4dGVybmFsIGZhY2lsaXR5IGFkaGVyZWQNCnRvIFAyUFNJUCwNCmp1c3Qg YXMgRE5TIHNlcnZpY2UgaXMgYW4gZXh0ZXJuYWwgZmFjaWx0aXkgb2YgU0lQLiANCg0KSSB0aGlu ayB0aGlzIHNob3VsZCBiZSBub3RpY2VkIHdoZW4gZGVmaW5pbmcgcGVlciBwcm90b2NvbC4NCg0K R2VuZ3l1DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQnJ1Y2UgTG93 ZWthbXAiIDxsb3dla2FtcEBzaXBlZXJpb3IuY29tPg0KVG86ICJXZWkgR2VuZ3l1IiA8d2VpZ2Vu Z3l1QHZpcC5zaW5hLmNvbT4NCkNjOiA8cDJwc2lwQGlldGYub3JnPg0KU2VudDogVGh1cnNkYXks IERlY2VtYmVyIDEzLCAyMDA3IDc6MDAgQU0NClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBSZTogSElQ IHByb3MgYW5kIGNvbnMNCg0KDQo+IEdlbmd5dSwNCj4gDQo+IE9uIERlYyAxMSwgMjAwNyA3OjM0 IEFNLCBXZWkgR2VuZ3l1IDx3ZWlnZW5neXVAdmlwLnNpbmEuY29tPiB3cm90ZToNCj4+IFdoZW4g eW91IHN1cHBvc2UgdGhhdCBQMlBTSVAgb3ZlcmxheSB3b3JrcyBpbiBhbiBlbnZpcm9ubWVudCB3 aXRob3V0DQpwcm92aXNpb25lZCBETlMgc3VwcG9ydCBmb3IgdGhlIG92ZXJsYXksDQo+PiB5b3Ug YWxzbyBzdXBwb3NlIHRoZXJlIGFyZSBub3Qgb3RoZXIgZmFjaWxpdGllcywgc3VjaCBhcyBQMlBO UywgdG8NCnN1cHBvcnQgZm9yIG1hcHBpbmcgaG9zdCBpZCB0byBJUCBhZGRyZXNzLg0KPj4gU28g eW91IGNvbmNsdWRlIHRoYXQgeW91IG5lZWQgdG8gZG8gbWFwcGluZyBhdCB0aGUgUDJQU0lQIG92 ZXJsYXkuDQpJbiB0aGlzIHNpdHVhdGlvbiBISVAgaXMgcmVxdWlyZWQuDQo+PiBEbyBJIHVuZGVy c3RhbmQgaXQgcmlnaHQ/DQo+Pg0KPiANCj4gSSdtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg UDJQTlMgdGhlcmUuICBJIHRoaW5rIGFsbCBvZiB0aGUgcGVlcg0KPiBwcm90b2NvbCBwcm9wb3Nh bHMgaGF2ZSB3YXlzIG9mIHNlYXJjaGluZyBpbiB0aGUgb3ZlcmxheSBhbmQNCj4gZXN0YWJsaXNo aW5nIGEgY29ubmVjdGlvbiB3aXRoIGEgc3BlY2lmaWMgcGVlci4gIENlcnRhaW5seSByZWxvYWQN Cj4gZG9lcy4gIEhJUCBpc24ndCBuZWVkZWQgdG8gc29sdmUgdGhhdCBwcm9ibGVtLg0KPiANCj4g QnJ1Y2UNCj4NCg== --===============0269283218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0269283218==-- From p2psip-bounces@ietf.org Fri Dec 14 12:29:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ELg-0003Qh-2k; Fri, 14 Dec 2007 12:29:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ELe-0003DZ-51 for p2psip@ietf.org; Fri, 14 Dec 2007 12:29:18 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3ELd-0003qH-RH for p2psip@ietf.org; Fri, 14 Dec 2007 12:29:18 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBEHT8tD010179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Dec 2007 11:29:09 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBEHT8aS023744; Fri, 14 Dec 2007 09:29:08 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBEHT8xG023732; Fri, 14 Dec 2007 09:29:08 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 09:29:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Fri, 14 Dec 2007 09:28:28 -0800 Message-ID: <0DF156EE7414494187B087A3C279BDB4080C53BF@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <000801c83e75$ce72b9a0$da07740a@dellwei> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg+dd5qaCDeMrFaSOqE916VYGFKrgAAEZAg References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com><002001c83e2d$29259b40$da07740a@dellwei><24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> <000801c83e75$ce72b9a0$da07740a@dellwei> From: "Ahrenholz, Jeffrey M" To: "Wei Gengyu" , "Henry Sinnreich" , "Bruce Lowekamp" X-OriginalArrivalTime: 14 Dec 2007 17:29:05.0996 (UTC) FILETIME=[D3C400C0:01C83E76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Gengyu, I think you may have misread RFC4423, in the introduction it states: "Each host will have at least one Host Identity, but it will=20 typically have more than one." The implementations also support multiple Host Identities and HITs per host. -Jeff > -----Original Message----- > From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 > Sent: Friday, December 14, 2007 9:21 AM > To: Henry Sinnreich; Bruce Lowekamp > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons >=20 > There is one possible problem. >=20 > HIP has already been standardized for Hosd indentification in=20 > rfc4423.=20 > Each host would have only one HIT according to RFC4423. > Peer ID is an identifier of Peer entity in P2PSIP overlay (at=20 > application layer of Internet). > There is a proposal of using HIT as Peer ID, so a host could=20 > only have one Peer entity. >=20 > But, if there are two or more Peer entities located at one=20 > host, how could you manage them? > In general, I think, it is possible that more than one Peer=20 > entity located at one host. =20 >=20 > How do you think of this? >=20 > Gengyu _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 12:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Em3-0000HS-Eo; Fri, 14 Dec 2007 12:56:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Em1-0008Te-O2 for p2psip@ietf.org; Fri, 14 Dec 2007 12:56:33 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Em1-0003l8-Fh for p2psip@ietf.org; Fri, 14 Dec 2007 12:56:33 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J3Elx-0005uh-1a; Fri, 14 Dec 2007 12:56:29 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE400@namail5.corp.adobe.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE400@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B9899EC-424E-473B-B277-DA48EE619919@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Fri, 14 Dec 2007 12:56:32 -0500 To: "Henry Sinnreich" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry: HIP is using ICE, so you won't see higher success ratios with HIP. What you WILL see is a better interface to the application. With all three HIP-based proposals that I know about, the details of the NAT traversal are hidden from the application. So there is no need to invent ICE-for-XXX, where XXX is {SIP, MSRP, Jabber, HTTP, SSH, etc. etc. etc.}. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 15:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HQ9-00036h-0b; Fri, 14 Dec 2007 15:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HQ7-00032f-FF for p2psip@ietf.org; Fri, 14 Dec 2007 15:46:07 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3HQ5-0000IQ-Cz for p2psip@ietf.org; Fri, 14 Dec 2007 15:46:07 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT2005604CS70@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 14 Dec 2007 12:46:04 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JT200BQ84CL4E@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 14 Dec 2007 12:46:04 -0800 (PST) Date: Fri, 14 Dec 2007 14:45:37 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Re: HIP pros and cons To: p2psip@ietf.org Message-id: <11ee01c83e92$482327f0$f7168182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <000c01c83bf2$3aa1dd30$da07740a@dellwei> <20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> <000801c83e75$ce72b9a0$da07740a@dellwei> <0DF156EE7414494187B087A3C279BDB4080C53BF@XCH-NW-6V1.nw.nos.boeing.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It's also worth pointing out a couple of other things. From Section 1 ("Disclaimer"): 1. Disclaimer The purpose of this memo is to provide a stable reference point in the development of the Host Identity Protocol architecture. This memo describes the thinking of the authors as of Fall 2003; their thinking may have evolved since then. Occasionally, this memo may be confusing or self-contradicting. That is (partially) intentional, and it reflects the snapshot nature of this memo. Pekka graciously took over the editor pen on Bob's draft so we'd have an architecture document as a starting point, but since HIP was chartered as a working group, it wasn't appropriate for him to write lots of text updating the draft as an individual. He didn't update the draft based on his own opinions. RFC4423 is a snapshot, not a final specification, and This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review. However, the ideas put forth in this RFC have generated significant interest, including the formation of the IETF HIP Working Group and the IRTF HIP Research Group. These groups are expected to generate further documents, sharing their findings with the whole Internet community. RFC4423 didn't standardize HIP, not even the HIP architecture. Not surprising that people miss this because (1) the "not a candidate for a standard" is usually provided as an "IESG Note" in more recent RFCs (sse http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg04080.html for an example), and (2) many people assume that RFCs are standards, although there are many RFCs that aren't standards (see http://www.ietf.org/rfc/rfc1796.txt). Thanks, Spencer (who helped with the final editing, among others) ----- Original Message ----- From: "Ahrenholz, Jeffrey M" To: "Wei Gengyu" ; "Henry Sinnreich" ; "Bruce Lowekamp" Cc: Sent: Friday, December 14, 2007 11:28 AM Subject: RE: [P2PSIP] Re: HIP pros and cons Gengyu, I think you may have misread RFC4423, in the introduction it states: "Each host will have at least one Host Identity, but it will typically have more than one." The implementations also support multiple Host Identities and HITs per host. -Jeff > -----Original Message----- > From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > Sent: Friday, December 14, 2007 9:21 AM > To: Henry Sinnreich; Bruce Lowekamp > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > There is one possible problem. > > HIP has already been standardized for Hosd indentification in > rfc4423. > Each host would have only one HIT according to RFC4423. > Peer ID is an identifier of Peer entity in P2PSIP overlay (at > application layer of Internet). > There is a proposal of using HIT as Peer ID, so a host could > only have one Peer entity. > > But, if there are two or more Peer entities located at one > host, how could you manage them? > In general, I think, it is possible that more than one Peer > entity located at one host. > > How do you think of this? > > Gengyu _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 15:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HVU-0007ec-Sv; Fri, 14 Dec 2007 15:51:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HVT-0007eX-Aj for p2psip@ietf.org; Fri, 14 Dec 2007 15:51:39 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3HVS-0000Qi-0C for p2psip@ietf.org; Fri, 14 Dec 2007 15:51:39 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J3HVQ-00015H-1U; Fri, 14 Dec 2007 15:51:36 -0500 In-Reply-To: <000801c83e75$ce72b9a0$da07740a@dellwei> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> <000801c83e75$ce72b9a0$da07740a@dellwei> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Fri, 14 Dec 2007 15:51:37 -0500 To: Wei Gengyu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Henry Sinnreich , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org 1) HIP explicitly allows a node to have multiple Host Identities (or HITs). 2) The HIP-HOP proposal was to allow a node to use its HIT as a peer ID in multiple overlays. However, EKR has pointed out a problem with this approach. To avoid long debate on this subject, I suggest we all just assume that a peer ID is NOT the same thing as the HIT. So a node might have just one HIT, but multiple peer IDs (one for each overlay in which it is a member). - Philip On 14-Dec-07, at 12:21 , Wei Gengyu wrote: > There is one possible problem. > > HIP has already been standardized for Hosd indentification in rfc4423. > Each host would have only one HIT according to RFC4423. > Peer ID is an identifier of Peer entity in P2PSIP overlay (at > application layer of Internet). > There is a proposal of using HIT as Peer ID, so a host could only > have one Peer entity. > > But, if there are two or more Peer entities located at one host, > how could you manage them? > In general, I think, it is possible that more than one Peer entity > located at one host. > > How do you think of this? > > Gengyu > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 16:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3IIR-0005C0-Sw; Fri, 14 Dec 2007 16:42:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3IIQ-0005B9-Pt for p2psip@ietf.org; Fri, 14 Dec 2007 16:42:14 -0500 Received: from exprod6og101.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3IIQ-0001sj-9s for p2psip@ietf.org; Fri, 14 Dec 2007 16:42:14 -0500 Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Dec 2007 13:42:05 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBELdiin009214; Fri, 14 Dec 2007 13:39:44 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBELfwRC008445; Fri, 14 Dec 2007 13:41:58 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 13:41:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Fri, 14 Dec 2007 13:38:19 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE408@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg+kx9q2iP/Y9aKRgS5KgjQJMbXVAABe2iA References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> <000801c83e75$ce72b9a0$da07740a@dellwei> From: "Henry Sinnreich" To: "Philip Matthews" , "Wei Gengyu" X-OriginalArrivalTime: 14 Dec 2007 21:41:58.0531 (UTC) FILETIME=[274D1D30:01C83E9A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil,=20 > So a node might have just one HIT, but multiple peer IDs >(one for each overlay in which it is a member). This is correct, although there is more to it. One node may carry several applications (SIP, Games, etc.) and they don't have each and all to worry about NAT traversal and ICE API's, since it is done only once at the HIP level. It was mentioned in an earlier message. Is this correct? Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Friday, December 14, 2007 2:52 PM To: Wei Gengyu Cc: Henry Sinnreich; Bruce Lowekamp; p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons 1) HIP explicitly allows a node to have multiple Host Identities (or =20 HITs). 2) The HIP-HOP proposal was to allow a node to use its HIT as a peer =20 ID in multiple overlays. However, EKR has pointed out a problem with this approach. To avoid long debate on this subject, I suggest we all just assume that a peer ID is NOT the same thing as the HIT. So a node might have just one HIT, but multiple peer IDs (one for each overlay in which it is a member). - Philip On 14-Dec-07, at 12:21 , Wei Gengyu wrote: > There is one possible problem. > > HIP has already been standardized for Hosd indentification in rfc4423. > Each host would have only one HIT according to RFC4423. > Peer ID is an identifier of Peer entity in P2PSIP overlay (at =20 > application layer of Internet). > There is a proposal of using HIT as Peer ID, so a host could only =20 > have one Peer entity. > > But, if there are two or more Peer entities located at one host, =20 > how could you manage them? > In general, I think, it is possible that more than one Peer entity =20 > located at one host. > > How do you think of this? > > Gengyu > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 14 17:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JIy-0006BQ-Rt; Fri, 14 Dec 2007 17:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JIy-0006BL-4d for p2psip@ietf.org; Fri, 14 Dec 2007 17:46:52 -0500 Received: from exprod6og102.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3JIx-0003CU-OF for p2psip@ietf.org; Fri, 14 Dec 2007 17:46:52 -0500 Received: from source ([192.150.20.142]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Fri, 14 Dec 2007 14:46:46 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBEMkeGb004795; Fri, 14 Dec 2007 14:46:43 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBEMkdRC019203; Fri, 14 Dec 2007 14:46:39 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 07:46:39 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP DHT interface (was HIP pros and cons) Date: Fri, 14 Dec 2007 14:46:30 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE40B@namail5.corp.adobe.com> In-Reply-To: <6B9899EC-424E-473B-B277-DA48EE619919@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP DHT interface (was HIP pros and cons) Thread-Index: Acg+eq14bKRUlKLhSZKqF59HRVAYYwAKBH7Q References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3DF@namail5.corp.adobe.com> <4D377884-C6B8-4A28-835D-4F3D1D9C335C@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE3EE@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE3F7@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE400@namail5.corp.adobe.com> <6B9899EC-424E-473B-B277-DA48EE619919@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 14 Dec 2007 22:46:39.0237 (UTC) FILETIME=[3061DB50:01C83EA3] X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, >What you WILL see is a better interface to the application. >With all three HIP-based proposals that I know about, the details >of the NAT traversal are hidden from the application. So there is >no need to invent ICE-for-XXX, where XXX is {SIP, MSRP, Jabber, >HTTP, SSH, etc. etc. etc.}. Exactly! That's it. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Friday, December 14, 2007 11:57 AM To: Henry Sinnreich Cc: Miika Komu; Bruce Lowekamp; jeffrey.m.ahrenholz@boeing.com; p2psip@ietf.org Subject: Re: [P2PSIP] HIP DHT interface (was HIP pros and cons) Henry: HIP is using ICE, so you won't see higher success ratios with HIP. What you WILL see is a better interface to the application. With all three HIP-based proposals that I know about, the details of the NAT traversal are hidden from the application. So there is no need to invent ICE-for-XXX, where XXX is {SIP, MSRP, Jabber, HTTP, SSH, etc. etc. etc.}. - Philip=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 15 12:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3bD0-0002Y7-4J; Sat, 15 Dec 2007 12:53:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3bCy-0002Xy-4G for p2psip@ietf.org; Sat, 15 Dec 2007 12:53:52 -0500 Received: from exprod6og101.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3bCx-0003st-NB for p2psip@ietf.org; Sat, 15 Dec 2007 12:53:52 -0500 Received: from source ([192.150.20.142]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP; Sat, 15 Dec 2007 09:53:49 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBFHrlGb024808 for ; Sat, 15 Dec 2007 09:53:48 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBFHraRE011094 for ; Sat, 15 Dec 2007 09:53:46 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Dec 2007 09:53:45 -0800 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 Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Sat, 15 Dec 2007 09:53:35 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg9Whc2pxlrvpiUTLSP4xY/tax8egB6O6eA References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> From: "Henry Sinnreich" To: X-OriginalArrivalTime: 15 Dec 2007 17:53:45.0707 (UTC) FILETIME=[7027BBB0:01C83F43] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Na=EFve question: Since HIP ESP data traffic is protected like in a VPN, are TLS, DTLS = SRTP still required? I would just like to be sure on this topic. Thanks, Henry _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 15 16:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ejq-0007Es-9f; Sat, 15 Dec 2007 16:40:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ejp-0007Ef-In for p2psip@ietf.org; Sat, 15 Dec 2007 16:40:01 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3ejp-0003Mc-8A for p2psip@ietf.org; Sat, 15 Dec 2007 16:40:01 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J3ejn-0002e6-2M; Sat, 15 Dec 2007 16:39:59 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE408@namail5.corp.adobe.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><000c01c83bf2$3aa1dd30$da07740a@dellwei><20d2bdfb0712121500se881be8yf37adcb228b1bc22@mail.gmail.com> <002001c83e2d$29259b40$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE3FF@namail5.corp.adobe.com> <000801c83e75$ce72b9a0$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE408@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <981670B2-3158-4627-852B-9962B4E684AB@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Sat, 15 Dec 2007 16:40:00 -0500 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 14-Dec-07, at 16:38 , Henry Sinnreich wrote: > Phil, > >> So a node might have just one HIT, but multiple peer IDs >> (one for each overlay in which it is a member). > > This is correct, although there is more to it. > One node may carry several applications (SIP, Games, etc.) and they > don't have each and all to worry about NAT traversal and ICE API's, > since it is done only once at the HIP level. > > It was mentioned in an earlier message. Is this correct? > Absolutely correct. This is one of the big advantages that I see of the HIP approach. All three of the existing HIP-based proposals have this property. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 15 18:14:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3gCu-0006ue-K8; Sat, 15 Dec 2007 18:14:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3gCt-0006uZ-OQ for p2psip@ietf.org; Sat, 15 Dec 2007 18:14:07 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3gCt-0003mr-7Q for p2psip@ietf.org; Sat, 15 Dec 2007 18:14:07 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J3gCr-00070P-2z; Sat, 15 Dec 2007 18:14:06 -0500 In-Reply-To: <002c01c83ec1$c5e5c880$da07740a@dellwei> References: <002c01c83ec1$c5e5c880$da07740a@dellwei> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Sat, 15 Dec 2007 18:14:08 -0500 To: "Wei Gengyu" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1610956958==" Errors-To: p2psip-bounces@ietf.org --===============1610956958== Content-Type: multipart/alternative; boundary=Apple-Mail-11-409916442 --Apple-Mail-11-409916442 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Gengyu: If I understand correctly, you are asking about what happens if a node has multiple peer ids in the same overlay. I suspect that you might be right that this is a security problem, and if it is, then whatever system is being used to generate peer ids must prevent this from occurring. As EKR has pointed out, the method if generating peer ids is out-of-scope, so we can just assume that the system (whatever it is) will take care of it. - Philip On 14-Dec-07, at 21:25 , Wei Gengyu wrote: > Jeff,Spencer, and Philip, > > First, thank you all for your correction. > > HIP might work well as RFC4423 defined. > > My problem is when HIP is used at the application layer, > or using the same algorithm to generate Peer ID. > > If HIP-like algorithm is used in the overlay while HIP is used > between network layer and transport layer, > the Peer ID will share the same name space with Host ID. > For rfc4423, when a node have multiple Host IDs, they only cost > memory spaces a little. > If one host are permited to have multiple Peer IDs that happen to > belong to one overlay, > it would incur potential risks to the P2PSIP overlay. > > And it seems not be capable to tackle this case in RVS of HIP. > Is there something wrong? > > Regars, > > Gengyu --Apple-Mail-11-409916442 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Gengyu:

If I = understand correctly, you are asking about what happens if a node has = multiple peer ids in the same overlay. I suspect that you might be right = that this is a security problem, and if it is, then whatever system is = being used to generate peer ids must prevent this from occurring. As EKR = has pointed out, the method if generating peer ids is out-of-scope, so = we can just assume that the system (whatever it is) will take care of = it.

- = Philip

On 14-Dec-07, at 21:25 , Wei Gengyu = wrote:

Jeff,Spencer, = and Philip,
=A0
First, thank you all for your = correction.
=A0
HIP might work=A0well as RFC4423 = defined.
=A0
My problem is when=A0HIP is used at the application = layer,
or using the same algorithm to = generate Peer ID.
=A0
If HIP-like = algorithm=A0is used in the overlay while=A0HIP is used between network = layer and transport layer,
the Peer ID = will share the same name space with Host ID.
For rfc4423,=A0when a node have = multiple Host IDs,=A0they=A0only cost memory spaces a = little.
If one host are = permited to have multiple Peer IDs that happen to belong to one = overlay,
it=A0would incur potential = risks to the P2PSIP overlay.
=A0
And=A0it seems not be = capable to tackle this case in RVS=A0of HIP.=A0
Is there something wrong?
=A0
Regars,
=A0
Gengyu

<= /html>= --Apple-Mail-11-409916442-- --===============1610956958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1610956958==-- From p2psip-bounces@ietf.org Sun Dec 16 06:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3rci-0006lc-Sc; Sun, 16 Dec 2007 06:25:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3rch-0006lX-QI for p2psip@ietf.org; Sun, 16 Dec 2007 06:25:31 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3rcf-00025A-68 for p2psip@ietf.org; Sun, 16 Dec 2007 06:25:31 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 60D4A1DD5C3 for ; Sun, 16 Dec 2007 19:25:24 +0800 (CST) Message-ID: <001201c83fd6$58430e80$da07740a@dellwei> From: "Wei Gengyu" To: "P2PSIP Mailing List" Subject: Fw: [P2PSIP] Re: HIP pros and cons Date: Sun, 16 Dec 2007 19:25:17 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0982498749==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0982498749== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C84019.63B2EE50" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C84019.63B2EE50 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogV2VpIEdlbmd5dSANClRvOiBq ZWZmcmV5Lm0uYWhyZW5ob2x6QGJvZWluZy5jb20gOyBzcGVuY2VyQG1jc3ItbGFicy5vcmcgOyBQ aGlsaXAgTWF0dGhld3MgDQpDYzogUDJQU0lQIE1haWxpbmcgTGlzdCANClNlbnQ6IFNhdHVyZGF5 LCBEZWNlbWJlciAxNSwgMjAwNyAxMDoyNSBBTQ0KU3ViamVjdDogUmU6IFtQMlBTSVBdIFJlOiBI SVAgcHJvcyBhbmQgY29ucw0KDQoNCkplZmYsU3BlbmNlciwgYW5kIFBoaWxpcCwgDQoNCkZpcnN0 LCB0aGFuayB5b3UgYWxsIGZvciB5b3VyIGNvcnJlY3Rpb24uDQoNCkhJUCBtaWdodCB3b3JrIHdl bGwgYXMgUkZDNDQyMyBkZWZpbmVkLg0KDQpNeSBwcm9ibGVtIGlzIHdoZW4gSElQIGlzIHVzZWQg YXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLCANCm9yIHVzaW5nIHRoZSBzYW1lIGFsZ29yaXRobSB0 byBnZW5lcmF0ZSBQZWVyIElELiANCg0KSWYgSElQLWxpa2UgYWxnb3JpdGhtIGlzIHVzZWQgaW4g dGhlIG92ZXJsYXkgd2hpbGUgSElQIGlzIHVzZWQgYmV0d2VlbiBuZXR3b3JrIGxheWVyIGFuZCB0 cmFuc3BvcnQgbGF5ZXIsDQp0aGUgUGVlciBJRCB3aWxsIHNoYXJlIHRoZSBzYW1lIG5hbWUgc3Bh Y2Ugd2l0aCBIb3N0IElELg0KRm9yIHJmYzQ0MjMsIHdoZW4gYSBub2RlIGhhdmUgbXVsdGlwbGUg SG9zdCBJRHMsIHRoZXkgb25seSBjb3N0IG1lbW9yeSBzcGFjZXMgYSBsaXR0bGUuDQpJZiBvbmUg aG9zdCBhcmUgcGVybWl0ZWQgdG8gaGF2ZSBtdWx0aXBsZSBQZWVyIElEcyB0aGF0IGhhcHBlbiB0 byBiZWxvbmcgdG8gb25lIG92ZXJsYXksIA0KaXQgd291bGQgaW5jdXIgcG90ZW50aWFsIHJpc2tz IHRvIHRoZSBQMlBTSVAgb3ZlcmxheS4NCg0KQW5kIGl0IHNlZW1zIG5vdCBiZSBjYXBhYmxlIHRv IHRhY2tsZSB0aGlzIGNhc2UgaW4gUlZTIG9mIEhJUC4gDQpJcyB0aGVyZSBzb21ldGhpbmcgd3Jv bmc/DQoNClJlZ2FycywNCg0KR2VuZ3l1 ------=_NextPart_000_000F_01C84019.63B2EE50 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMyNDMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5SI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCjxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNr Ij48Qj5Gcm9tOjwvQj4gPEEgDQp0aXRsZT13ZWlnZW5neXVAdmlwLnNpbmEuY29tIGhyZWY9Im1h aWx0bzp3ZWlnZW5neXVAdmlwLnNpbmEuY29tIj5XZWkgR2VuZ3l1PC9BPiANCjwvRElWPg0KPERJ Vj48Qj5Ubzo8L0I+IDxBIHRpdGxlPWplZmZyZXkubS5haHJlbmhvbHpAYm9laW5nLmNvbSANCmhy ZWY9Im1haWx0bzpqZWZmcmV5Lm0uYWhyZW5ob2x6QGJvZWluZy5jb20iPmplZmZyZXkubS5haHJl bmhvbHpAYm9laW5nLmNvbTwvQT4gDQo7IDxBIHRpdGxlPXNwZW5jZXJAbWNzci1sYWJzLm9yZyAN CmhyZWY9Im1haWx0bzpzcGVuY2VyQG1jc3ItbGFicy5vcmciPnNwZW5jZXJAbWNzci1sYWJzLm9y ZzwvQT4gOyA8QSANCnRpdGxlPXBoaWxpcF9tYXR0aGV3c0BtYWdtYS5jYSBocmVmPSJtYWlsdG86 cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIj5QaGlsaXAgDQpNYXR0aGV3czwvQT4gPC9ESVY+DQo8 RElWPjxCPkNjOjwvQj4gPEEgdGl0bGU9cDJwc2lwQGlldGYub3JnIGhyZWY9Im1haWx0bzpwMnBz aXBAaWV0Zi5vcmciPlAyUFNJUCANCk1haWxpbmcgTGlzdDwvQT4gPC9ESVY+DQo8RElWPjxCPlNl bnQ6PC9CPiBTYXR1cmRheSwgRGVjZW1iZXIgMTUsIDIwMDcgMTA6MjUgQU08L0RJVj4NCjxESVY+ PEI+U3ViamVjdDo8L0I+IFJlOiBbUDJQU0lQXSBSZTogSElQIHByb3MgYW5kIGNvbnM8L0RJVj48 L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SmVmZixTcGVuY2VyLCBh bmQgUGhpbGlwLCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5GaXJzdCwgdGhhbmsgeW91IGFsbCBmb3IgeW91ciBj b3JyZWN0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhJUCBtaWdodCB3b3JrJm5ic3A7d2VsbCBhcyBSRkM0 NDIzIGRlZmluZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+TXkgcHJvYmxlbSBpcyB3aGVuJm5ic3A7SElQIGlz IHVzZWQgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLCANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPm9yIHVzaW5nIHRoZSBzYW1lIGFsZ29yaXRobSB0byBnZW5lcmF0ZSBQZWVyIElE LiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5JZiBISVAtbGlrZSBhbGdvcml0aG0mbmJzcDtpcyB1c2VkIGluIHRo ZSBvdmVybGF5IA0Kd2hpbGUmbmJzcDtISVAgaXMgdXNlZCBiZXR3ZWVuIG5ldHdvcmsgbGF5ZXIg YW5kIHRyYW5zcG9ydCBsYXllciw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGUg UGVlciBJRCB3aWxsIHNoYXJlIHRoZSBzYW1lIG5hbWUgc3BhY2Ugd2l0aCBIb3N0IA0KSUQuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj5Gb3IgcmZj NDQyMywmbmJzcDt3aGVuIGEgbm9kZSBoYXZlIG11bHRpcGxlIEhvc3QgSURzLCANCjwvRk9OVD48 Rk9OVCBzaXplPTI+dGhleSZuYnNwO29ubHkgY29zdCBtZW1vcnkgc3BhY2VzIGEgDQpsaXR0bGUu PC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklmIG9uZSBob3N0 IGFyZSBwZXJtaXRlZCB0byBoYXZlIG11bHRpcGxlIFBlZXIgSURzIHRoYXQgaGFwcGVuIA0KdG8g YmVsb25nIHRvIG9uZSBvdmVybGF5LCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5p dCZuYnNwO3dvdWxkIGluY3VyIHBvdGVudGlhbCByaXNrcyB0byB0aGUgUDJQU0lQIA0Kb3Zlcmxh eS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5BbmQmbmJzcDtpdCBzZWVtcyBub3QgYmUgY2FwYWJsZSB0byB0YWNr bGUgdGhpcyBjYXNlIGluIA0KUlZTJm5ic3A7b2YgSElQLiZuYnNwOzwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPklzIHRoZXJlIHNvbWV0aGluZyB3cm9uZz88L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5S ZWdhcnMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+R2VuZ3l1PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000F_01C84019.63B2EE50-- --===============0982498749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0982498749==-- From p2psip-bounces@ietf.org Sun Dec 16 16:07:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40i9-0002mH-Op; Sun, 16 Dec 2007 16:07:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J40i8-0002lz-JO for p2psip@ietf.org; Sun, 16 Dec 2007 16:07:44 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J40i8-0003CP-93 for p2psip@ietf.org; Sun, 16 Dec 2007 16:07:44 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J40i5-0002Ak-0k; Sun, 16 Dec 2007 16:07:41 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Sun, 16 Dec 2007 16:07:40 -0500 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Good question! The most straight-forward way to use HIP for P2PSIP is to protect ALL =20= traffic with ESP, thus making TLS, DTLS, and SRTP unnecessary. This =20 doesn't mean they cannot be used -- it just means that they are not =20 needed. - Philip On 15-Dec-07, at 12:53 , Henry Sinnreich wrote: > Na=EFve question: > > Since HIP ESP data traffic is protected like in a VPN, are TLS, =20 > DTLS SRTP still required? I would just like to be sure on this topic. > > Thanks, Henry > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 16 17:44:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42Dn-0005js-9m; Sun, 16 Dec 2007 17:44:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42Dl-0005jn-QJ for p2psip@ietf.org; Sun, 16 Dec 2007 17:44:29 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J42Dl-0005WR-EG for p2psip@ietf.org; Sun, 16 Dec 2007 17:44:29 -0500 Received: from p54a00847.dip0.t-ipconnect.de ([84.160.8.71] helo=[192.168.178.20]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J42Ca-0002P0-AE; Sun, 16 Dec 2007 23:43:16 +0100 Message-ID: <4765A9FF.7000903@uni-tuebingen.de> Date: Sun, 16 Dec 2007 23:43:11 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Henry Sinnreich , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip, I wouldn't bet on that. ESP can use also null encryption and null data integrity. (although the combination of both nulls is not allowed) In general, security mechanisms on the application layer shoudn't depend on security mechanisms in underlaying layers, in this case the HIP overlay layer. Cheers, Ali Philip Matthews wrote: > Good question! > > The most straight-forward way to use HIP for P2PSIP is to protect ALL > traffic with ESP, thus making TLS, DTLS, and SRTP unnecessary. This > doesn't mean they cannot be used -- it just means that they are not needed. > > - Philip > > On 15-Dec-07, at 12:53 , Henry Sinnreich wrote: > >> Naïve question: >> >> Since HIP ESP data traffic is protected like in a VPN, are TLS, DTLS >> SRTP still required? I would just like to be sure on this topic. >> >> Thanks, Henry >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 16 18:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42p7-00052p-SZ; Sun, 16 Dec 2007 18:23:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42p6-00052a-Ah for p2psip@ietf.org; Sun, 16 Dec 2007 18:23:04 -0500 Received: from exprod6og103.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J42p4-0004ik-3h for p2psip@ietf.org; Sun, 16 Dec 2007 18:23:04 -0500 Received: from source ([192.150.20.142]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Sun, 16 Dec 2007 15:22:58 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBGNMnGb028969; Sun, 16 Dec 2007 15:22:49 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBGNMkFX004193; Sun, 16 Dec 2007 15:22:48 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Dec 2007 15:22:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Sun, 16 Dec 2007 15:21:49 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> In-Reply-To: <001201c83fd6$58430e80$da07740a@dellwei> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: Acg/1nHrd7nWpMQHRqycQAubdLRbtgAY1jiw References: <001201c83fd6$58430e80$da07740a@dellwei> From: "Henry Sinnreich" To: "Wei Gengyu" , "P2PSIP Mailing List" X-OriginalArrivalTime: 16 Dec 2007 23:22:47.0227 (UTC) FILETIME=[916E60B0:01C8403A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0713927823==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0713927823== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8403A.8FD33948" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8403A.8FD33948 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > My problem is when HIP is used at the application layer,=20 > or using the same algorithm to generate Peer ID.=20 =20 HIP runs below the application layer and also below the p2p layer.=20 HI is different from the p2p nodeID or application layer (such as SIP) identifiers, such as AoR. =20 =20 Henry ________________________________ From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Sunday, December 16, 2007 5:25 AM To: P2PSIP Mailing List Subject: Fw: [P2PSIP] Re: HIP pros and cons =20 =20 ----- Original Message -----=20 From: Wei Gengyu =20 To: jeffrey.m.ahrenholz@boeing.com ; spencer@mcsr-labs.org ; Philip Matthews =20 Cc: P2PSIP Mailing List =20 Sent: Saturday, December 15, 2007 10:25 AM Subject: Re: [P2PSIP] Re: HIP pros and cons =20 Jeff,Spencer, and Philip,=20 =20 First, thank you all for your correction. =20 HIP might work well as RFC4423 defined. =20 My problem is when HIP is used at the application layer,=20 or using the same algorithm to generate Peer ID.=20 =20 If HIP-like algorithm is used in the overlay while HIP is used between network layer and transport layer, the Peer ID will share the same name space with Host ID. For rfc4423, when a node have multiple Host IDs, they only cost memory spaces a little. If one host are permited to have multiple Peer IDs that happen to belong to one overlay,=20 it would incur potential risks to the P2PSIP overlay. =20 And it seems not be capable to tackle this case in RVS of HIP.=20 Is there something wrong? =20 Regars, =20 Gengyu ------_=_NextPart_001_01C8403A.8FD33948 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

> My problem is when HIP is used at the application layer,

> or using the same algorithm to generate Peer ID. =

 

HIP runs below the application layer and also below the p2p layer. =

HI is different from the p2p nodeID or application layer (such as SIP) = identifiers, such as AoR.  

 

Henry

From: Wei = Gengyu [mailto:weigengyu@vip.sina.com]
Sent: Sunday, December = 16, 2007 5:25 AM
To: P2PSIP Mailing = List
Subject: Fw: [P2PSIP] Re: = HIP pros and cons

 

 

----- Original Message -----

From: Wei Gengyu =

Sent: Saturday, December 15, 2007 10:25 = AM

Subject: Re: [P2PSIP] Re: HIP pros and = cons

 

Jeff,Spencer, and Philip,

 

First, thank you all for your correction.

 

HIP might work well as RFC4423 defined.

 

My problem is when HIP is used at the application layer, =

or using the same algorithm to generate Peer ID. =

 

If HIP-like algorithm is used in the overlay while HIP is used = between network layer and transport layer,

the Peer ID will share the same name space with Host = ID.

For rfc4423, when a node have multiple Host IDs, they only cost = memory spaces a little.

If one host are permited to have multiple Peer IDs that happen to belong to = one overlay,

it would incur potential risks to the P2PSIP = overlay.

 

And it seems not be capable to tackle this case in RVS of = HIP. 

Is there something wrong?

 

Regars,

 

Gengyu

------_=_NextPart_001_01C8403A.8FD33948-- --===============0713927823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0713927823==-- From p2psip-bounces@ietf.org Sun Dec 16 18:28:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42ul-0003JZ-NG; Sun, 16 Dec 2007 18:28:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J42uk-0003AF-CR for p2psip@ietf.org; Sun, 16 Dec 2007 18:28:54 -0500 Received: from exprod6og102.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J42ui-0004sP-QM for p2psip@ietf.org; Sun, 16 Dec 2007 18:28:54 -0500 Received: from source ([192.150.20.142]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Sun, 16 Dec 2007 15:28:40 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBGNSbGb029271; Sun, 16 Dec 2007 15:28:38 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBGNSYRE000714; Sun, 16 Dec 2007 15:28:36 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 08:28:34 +0900 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 Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Sun, 16 Dec 2007 15:28:17 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE414@namail5.corp.adobe.com> In-Reply-To: <4765A9FF.7000903@uni-tuebingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: AchANTfEjxPFPPF4S0qYTGFdpHevlQABX98A References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> <4765A9FF.7000903@uni-tuebingen.de> From: "Henry Sinnreich" To: "Ali Fessi" , "Philip Matthews" X-OriginalArrivalTime: 16 Dec 2007 23:28:34.0841 (UTC) FILETIME=[60A01090:01C8403B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ali, > In general, security mechanisms on the application layer shoudn't = depend=20 > on security mechanisms in underlaying layers, We have no disagreement on the need for strong p2p authentication = provided by the enrollment service or server. However, do you have any specific reasons to duplicate the VPN-like = transmission security of HIP (that would be duplicated in TLS, DTL and = SRTP)? What would they be? Henry -----Original Message----- From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de]=20 Sent: Sunday, December 16, 2007 4:43 PM To: Philip Matthews Cc: Henry Sinnreich; p2psip@ietf.org Subject: Re: [P2PSIP] Re: HIP pros and cons Philip, I wouldn't bet on that. ESP can use also null encryption and null data=20 integrity. (although the combination of both nulls is not allowed) In general, security mechanisms on the application layer shoudn't depend = on security mechanisms in underlaying layers, in this case the HIP=20 overlay layer. Cheers, Ali Philip Matthews wrote: > Good question! >=20 > The most straight-forward way to use HIP for P2PSIP is to protect ALL=20 > traffic with ESP, thus making TLS, DTLS, and SRTP unnecessary. This=20 > doesn't mean they cannot be used -- it just means that they are not = needed. >=20 > - Philip >=20 > On 15-Dec-07, at 12:53 , Henry Sinnreich wrote: >=20 >> Na=EFve question: >> >> Since HIP ESP data traffic is protected like in a VPN, are TLS, DTLS=20 >> SRTP still required? I would just like to be sure on this topic. >> >> Thanks, Henry >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 --=20 Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 16 21:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J465t-0005ct-5s; Sun, 16 Dec 2007 21:52:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J465q-0005Yq-Tm for p2psip@ietf.org; Sun, 16 Dec 2007 21:52:35 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J465n-0001kh-Jy for p2psip@ietf.org; Sun, 16 Dec 2007 21:52:34 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT6000KIAM008@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 17 Dec 2007 10:51:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT600BE6ALY3V@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 17 Dec 2007 10:51:36 +0800 (CST) Received: from z52048 ([10.164.5.84]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JT600GXEALOBE@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 17 Dec 2007 10:51:34 +0800 (CST) Date: Mon, 17 Dec 2007 10:51:25 +0800 From: Zheng Hewen In-reply-to: <02bc01c83cec$91a90220$640fa8c0@cis.neustar.com> To: 'Brian Rosen' , 'Eunsoo Shim' Message-id: <000001c84057$b93a7e90$5405a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acg8z65J7Au1ATRxSJu8dt36pByXeAAHHOXwANqSSJA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' Subject: [P2PSIP] Proposal about P2PSIP client description in Concept document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Since we now have at least the consensus about P2PSIP client as below: (1). A client is a peer that does not do routing; (2). We will have clients that will have to do at least a get-put, all protocols will have to do that. A proposal is thrown out: the author(s) of the Concept document can update the Concept document to keep compatible with the consensus, this update will be significantly helpful to develop Peer/client protocol. The discussion about P2PSIP client in this WG mail list and the I-D "P2PSIP Clients" (http://tools.ietf.org/wg/p2psip/draft-pascual-p2psip-clients-00.txt) will provide helpful information. Any comment is appreciated. Best regards, Hewen > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 2007?12?13? 2:27 > To: 'Eunsoo Shim' > Cc: 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] client protocol architectural issues > > > > > -----Original Message----- > > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > > Sent: Wednesday, December 12, 2007 9:59 AM > > To: Brian Rosen > > Cc: Henry Sinnreich; lichun li; Bruce Lowekamp; P2PSIP Mailing List > > Subject: Re: [P2PSIP] client protocol architectural issues > > > > On Dec 11, 2007 10:47 AM, Brian Rosen wrote: > > > Henry > > > > > > Like most IETF work group, we're subject to scope creep. You are > > suggesting > > > scope creep; start working on non-SIP p2p before we have p2psip > > > standardized. > > > > > What do you mean by 'non-SIP p2p' and 'p2psip'? > p2psip <> non-SIP p2p > > We're working on the former, not the latter. > > > > > > You are free to propose a charter change. We'll see what > support it > > gets. > > > > > > Right now, it's out of scope. It's relevant enough that we'll > > > tolerate > > some > > > list discussion, but our scope is p2psip. > > > > > I think clients providing a storage function is as relevant > to p2psip > > as clients not providing a storage function is. > The consensus at the meeting was: > A client is a peer that does not do routing. > > There is no mention of "storage" in that definition. > Some protocol proposals allowed clients to store or not > store. That's ok, but not a requirement. > > Is that okay? > > Brian > > > > Thanks. > > > > Eunsoo > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Tuesday, December 11, 2007 10:24 AM > > > > To: Brian Rosen; lichun li; Bruce Lowekamp > > > > Cc: P2PSIP Mailing List > > > > Subject: RE: [P2PSIP] client protocol architectural issues > > > > > > > > I would like to sincerely congratulate the co-chairs for the > > > > excellent handling of the difficult WG meeting. Good job! > > > > > > > > But alas, nobody is perfect and I feel the client issue was > > > > handled in > > a > > > > heavy handed manner, showing an early manifest bias against > > > > clients > > and > > > > the client protocol. > > > > > > > > > but I don't want to spend > > > > > endless cycles debating the merits of proposals for #3 > > > > > > > > Option 3 is clearly the most interesting since it is the most > > powerful. > > > > > > > > If you put time and company resources into P2P, option > 3 is just > > > > too important for "I don't want to spend endless cycles > debating" > > > > and > > probably > > > > just have to do it. > > > > > > > > Since amending the WG charter was mentioned, the other > > > > applications, beyond SIP must also be taken into consideration, > > > > such as distributed directory and range searches as > well as other > > > > applications that make > > the > > > > P2PSIP "call" more valuable. > > > > > > > > My two cents, > > > > > > > > Henry > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, December 11, 2007 6:06 AM > > > > To: 'lichun li'; 'Bruce Lowekamp' > > > > Cc: 'P2PSIP Mailing List' > > > > Subject: RE: [P2PSIP] client protocol architectural issues > > > > > > > > I refer you to the minutes of the IETF70 meeting held last week: > > > > "We will have clients that will have to do at least a > get-put, all > > > > protocols will have to do that, and we'll not put a lot more > > > > meeting time into > > that > > > > for now" > > > > > > > > We observed that all of the proposed protocols have > such an option > > > > defined. > > > > That is #2. We clearly permit #1. > > > > > > > > At the moment, we're probably not going to want to > spend more time > > > > on option #3. If the chosen protocol has more, okay, > but I don't > > > > want to spend endless cycles debating the merits of > proposals for > > > > #3. > > > > > > > > Some list discussion on the subject is always > interesting as long > > > > as > > we > > > > don't divert too much attention from more central issues. I'd > > > > prefer > > to > > > > see > > > > that discussion focused on specifics, rather than generalities, > > > > but > > open > > > > discussion is always welcome. > > > > > > > > Brian > > > > > > > > > > > > > > > > ________________________________________ > > > > From: lichun li [mailto:lilichun@gmail.com] > > > > Sent: Monday, December 10, 2007 8:26 PM > > > > To: Bruce Lowekamp > > > > Cc: P2PSIP Mailing List > > > > Subject: Re: [P2PSIP] client protocol architectural issues > > > > > > > > I also think option1 and 2 are necessary.Maybe only one type of > > > > node > > is > > > > calledas "client" eventually. Butthere should be more than one > > > > type of node in P2PSIP other than peer. > > > > > > > > > > > > On Dec 11, 2007 3:18 AM, Bruce Lowekamp > > wrote: > > > > Eunsoo, > > > > > > > > I'm sorry, I will try to be more clear. > > > > > > > > My initial statement was that there are a range of > architectural > > > > options, which I listed as: > > > > - option 1: the only p2psip clients are sip devices > that speak sip > > > > with p2psip peers > > > > - option 2: there is a get/put client protocol that > allows non-sip > > > > interaction between clients and peers > > > > - option 3: there is a more complicated client protocol that > > > > allows "clients" to offer storage or other services to the peers > > > > > > > > > > > > The statement I made after that in my initial email was: > > > > > My personal belief is that the primary P2PSIP architecture > > > > > should be > > > > (1). > > > > I still support this, for a few reasons. First, observe that I > > > > made that statement about P2P*SIP* (emphasis added). It's SIP. > > > > Discussion of non-SIP is further down. In a P2P*SIP* > architecture, > > > > it seems reasonable to assume that many if not most of > the devices > > > > will be SIP devices. For compatibility with existing > SIP devices > > > > (which cannot possibly be peers), they will need a SIP > proxy for > > > > connectivity, which will most probably be a P2PSIP device. So > > > > that's SIP being used as a "client" protocol. Most devices that > > > > can speak the peer protocol, I will assume will be peers. There > > > > are some arguments for why a P2PSIP device can't be a peer, as > > > > your draft points out, and for almost all of those > scenarios, SIP will work fine. > > > > > > > > Now, there are a few deployment scenarios for P2PSIP where for > > > > some reason the clients can't use a P2PSIP peer as their proxy. > > > > Your draft listed some, and I think there are others. In those > > > > cases, I think option 2 is necessary. I think it's > necessary, it's > > > > just that the default should be option 1. > > > > > > > > I should add that I am assuming that if we choose to support > > > > option 2, p2psip implementations are still free to > support option > > > > 1, it's just that the peer protocol is required to > support option > > > > 2 (client get/put). > > > > > > > > Now, for non-SIP, well, the quick answer is that we're not > > > > chartered to work on non-SIP. So that's not a question about > > > > P2P*SIP*. But the longer answer is that I suspect most non-SIP > > > > applications will already have their own protocol, and I still > > > > believe that the vast majority of deployment scenarios should > > > > require no more than option 2 (although there are > obviously important applications of option 3 as well). > > > > > > > > Bruce > > > > > > > > > > > > On Dec 7, 2007 11:38 AM, Eunsoo Shim > wrote: > > > > > I don't quite understand how what you wrote below is > connected > > > > > to > > your > > > > > initial proposal that P2PSIP architecture should require all > > > > > devices/nodes (Peers and Clients) to be coupled with > SIP entities. > > > > > Could you explain again the reason of your proposal? > > > > > Thanks. > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp > > > wrote: > > > > > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < eunsooshim@gmail.com> > > wrote: > > > > > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp > > > > > > > > > > > > > wrote: > > > > > > > > For P2PSIP, one option for "clients" is essentially for > > > > > > > > the > > peer > > > > to > > > > be > > > > > > > > acting as a proxy for clients that speak only SIP and be > > totally > > > > > > > > unaware of the overlay. > > > > > > > > > > > > > > Other protocols will likely have their own > > > > > > > > way of using the peer as a client without being > aware of > > > > > > > > the > > > > overlay. > > > > > > > > > > > > > > > > > > > > > > This is a problem with removing the concept of Clients in > > > > > > > the > > > > overlay > > > > layer. > > > > > > > If there is the Client node type, application protocols > > > > > > > don't > > need > > > > to > > > > > > > have their own way to support client-like devices. > > > > > > > > > > > > > > > > > > > My point is very simple. Most applications that have been > > discussed > > > > > > already exist before a p2p version has been created. So they > > already > > > > > > have this protocol. > > > > > > > > > > > > > > > > > > > > > > > > 2 says that whatever the application is, the > > > > > > > > > > application > > will > > > > be > > > > able > > > > > > > > > > to use GET/STORE to provide provides the lookup and > > > > CONNECT/TUNNEL > > > > > > > > > > provide connectivity if the target is behind a NAT. > > > > > > > > > > > > > > > > > > > > 3 says that there is some need for these nodes to > > > > > > > > > > interact > > at > > > > a > > > > more > > > > > > > > > > basic, non-application way, that is not simply doing > > location > > > > for that > > > > > > > > > > application. It has nothing to do with non-SIP, it > > > > > > > > > > means > > that > > > > > > > > > > whatever the application is, it's non-application. > > > > > > > > > > > > > > > > > > > I don't understand this either. > > > > > > > > > > > > > > > > 2 is clients use the overlay's get/put. So they know the > > overlay > > > > > > > > exists and speak the p2p protocol, but don't provide > > > > > > > > storage > > to > > > > the > > > > > > > > overlay, they just use it to resolve lookups. > > > > > > > > > > > > > > > > 3 says that the clients will need to do more than just > > > > > > > > simple > > > > get/put. > > > > > > > > Trying to contribute storage to the peer would > be the most > > > > obvious > > > > > > > > example of this. > > > > > > > > > > > > > > > > > > > > > > (2) and (3) have nothing to do with whether some nodes in > > > > > > > the > > > > overlay > > > > > > > layer may or may not be coupled with SIP > entities. What you > > > > > > > are talking about is whether the Clients will do in the > > > > > > > overlay > > layer > > > > more > > > > > > > than just using the overlay with GET/PUT. > > > > > > > > > > > > Exactly. SIP (since it's what we're chartered for) > is just the > > > > > > primary working example of an application. > > > > > > > > > > > > Bruce > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Eunsoo > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > -- > > > > Sincerely yours, > > > > > > > > Lichun Li > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > -- > > Eunsoo > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 16 22:00:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J46Di-000632-Ja; Sun, 16 Dec 2007 22:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J46Dh-00060J-GN for p2psip@ietf.org; Sun, 16 Dec 2007 22:00:41 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J46Dd-0007wr-Vx for p2psip@ietf.org; Sun, 16 Dec 2007 22:00:41 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id CFECB286F3; Mon, 17 Dec 2007 11:00:32 +0800 (CST) Message-ID: <000001c84058$fabe14c0$da07740a@dellwei> From: "Wei Gengyu" To: "Henry Sinnreich" References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Mon, 17 Dec 2007 10:58:53 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2057287697==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2057287697== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A3_01C8409B.D048A730" This is a multi-part message in MIME format. ------=_NextPart_000_00A3_01C8409B.D048A730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVucnksDQogIA0KSSBhbSB2ZXJ5IGFwcHJlY2lhdGVkIHlvdXIgY29tbWVudHMuIEFuZCBubyBu ZXcgcXVlc3Rpb25zIGFib3V0IHRoaXMgdGhyZWFkLg0KDQpCdXQgSSBob3BlIHRvIGdldCBoaW50 cyBvbiBzb21lIGFscmVhZHkgcmFpc2VkIHF1ZXN0aW9ucy4gDQpXb3VsZCB5b3UgcGxlYXNlIGhl bHAgbWUgY2xhcmlmeSB0aGF0Pw0KDQpXaGF0IGlzIHAycCBsYXllcj8gV2hhdCBkbyB5b3UgbWVh biAicDJwIGxheWVyIj8NCg0KSW4gImRyYWZ0LW1hdHRoZXdzLXAycHNpcC1oaXAtaG9wLTAwLiIs d2UgY2FuIHNlZSAncDJwLWxheWVycycgDQp0aGF0IGluY2x1ZGluZyBJUHY0IG9yIElQdjYsIFVE UHY0IG9yIFVEUHY2PywgSElQIG9yIEVTUCwgVENQIG9yIFVEUCwgYW5kIGRpc3RyaWJ1dGVkIGRh dGFiYXNlLiANClRoZSAncDJwIGxheWVycydjb250YWluIGZpdmUgbGF5ZXJzLiANCg0KSSBuZWVk IHRvIGtub3cgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAicDJwIGxheWVyIiBhbmQgJ3AycCBsYXll cnMnLg0KU28sIEkgc2hhbGwgc2VlIHdoZXJlIHlvdSBwdXQgSElQIHVuZGVyIHAycCBsYXllci4N Cg0KSW4gImRyYWZ0LWhhdXRha29ycGktcDJwc2lwLXdpdGgtaGlwLTAxLnR4dCIsIHRoZXJlIGFy ZSBmb3VyIHN1Z2dlc3Rpb25zIGluIHByb3RvY29sIGxheWVyIHNjaGVtZS4NCk9ubHkgKGEpIG9m IEZpZ3VyZSAzIGNvbnRhaW5zIEhJUCwgYnV0IEhJUCBpcyBzZXQgb24gdG9wIG9mIFBlZXIgcHJv dG9jb2wuDQp3aGlzdCB0aGVyZSBpcyBubyB3b3JkcyBvZiAicDJwIGxheWVyIiwgaXQgc2VlbXMg dGhhdCBQZWVyIHByb3RvY29sIHNob3VsZCBhdCB0aGF0IGxheWVyLg0KDQpSZWZlciB0byAgImRy YWZ0LXdpbGxpcy1wMnBzaXAtY29uY2VwdHMtMDQgLSBDb25jZXB0cyBhbmQgVGVybWlub2xvZ3kg Zm9yIFBlZXIgdG8gUGVlciBTSVAiLA0KIjIuICBIaWdoIExldmVsIERlc2NyaXB0aW9uDQoNCiAg IEEgUDJQU0lQIE92ZXJsYXkgaXMgYSBjb2xsZWN0aW9uIG9mIG5vZGVzIG9yZ2FuaXplZCBpbiBh IHBlZXItdG8tcGVlcg0KICAgZmFzaGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgZW5hYmxpbmcgcmVh bC10aW1lIGNvbW11bmljYXRpb24gdXNpbmcgdGhlDQogICBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCkuICBDb2xsZWN0aXZlbHksIHRoZSBub2RlcyBpbiB0aGUNCiAgIG92ZXJsYXkg cHJvdmlkZSBhIGRpc3RyaWJ1dGVkIGltcGxlbWVudGF0aW9uIG9mIHRoZSBsb2NhdGlvbiBzZXJ2 aWNlDQogICBbUkZDMzI2MV0gZm9yIG1hcHBpbmcgQWRkcmVzc2VzIG9mIFJlY29yZCAoQW9Scykg dG8gQ29udGFjdCBVUklzLg0KICAgVGhleSBhbHNvIHByb3ZpZGUgYSB0cmFuc3BvcnQgc2Vydmlj ZSBieSB3aGljaCBTSVAgbWVzc2FnZXMgY2FuIGJlDQogICB0cmFuc3BvcnRlZCBiZXR3ZWVuIGFu eSB0d28gbm9kZXMgaW4gdGhlIG92ZXJsYXkuDQoNCiAgIEEgUDJQU0lQIE92ZXJsYXkgY29uc2lz dHMgb2Ygb25lIG9yIG1vcmUgbm9kZXMgY2FsbGVkIFAyUFNJUCBQZWVycy4NCiAgIFRoZSBwZWVy cyBpbiB0aGUgb3ZlcmxheSBjb2xsZWN0aXZlbHkgcnVuIGEgZGlzdHJpYnV0ZWQgZGF0YWJhc2UN CiAgIGFsZ29yaXRobS4gIFRoaXMgZGlzdHJpYnV0ZWQgZGF0YWJhc2UgYWxnb3JpdGhtIGFsbG93 cyBkYXRhIHRvIGJlDQogICBzdG9yZWQgb24gcGVlcnMgYW5kIHJldHJpZXZlZCBpbiBhbiBlZmZp Y2llbnQgbWFubmVyLiAgSXQgbWF5IGFsc28NCiAgIGVuc3VyZSB0aGF0IGEgY29weSBvZiBhIGRh dGEgaXRlbSBpcyBzdG9yZWQgb24gbW9yZSB0aGFuIG9uZSBwZWVyLCBzbw0KICAgdGhhdCB0aGUg bG9zcyBvZiBhIHBlZXIgZG9lcyBub3QgcmVzdWx0IGluIHRoZSBsb3NzIG9mIHRoZSBkYXRhIGl0 ZW0NCiAgIHRvIHRoZSBvdmVybGF5LiAgICINCg0KVW5mb3J1bmF0ZWx5LCB0aGVyZSBpcyBubyBl eHBsaWNpdCBkZWZpbml0aW9uIG9mICJwMnAgbGF5ZXIiIGluIHRoZSBJLUQNCmFsdGhvdWdoIHNv IG1hbnkgcGVvcGxlIHNheSAicDJwIGxheWVyIiBpbiB0aGlzIG1haWxpbmcgbGlzdC4NCg0KRXZl biBpdCBzZWVtcyB0byBiZSBhIHNpbGx5IHF1ZXRpb24sICJwMnAgbGF5ZXIiIGlzIHN0aWxsIGEg dmFndWUgY29uY2VwdCB3aGVuIHBlb3BsZSBzYXkgaXQuDQpTbywgSSB0aGluayB0aGF0IFdHIG5l ZWRzIHRvIG1ha2UgdGhpcyBiYXNpYyBkZWZpbml0aW9uIGNsZWFyLiANCg0KQmVzdCByZWdhcmRz LA0KDQpHZW5neXUgDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEhl bnJ5IFNpbm5yZWljaCANCiAgVG86IFdlaSBHZW5neXUgOyBQMlBTSVAgTWFpbGluZyBMaXN0IA0K ICBTZW50OiBNb25kYXksIERlY2VtYmVyIDE3LCAyMDA3IDc6MjEgQU0NCiAgU3ViamVjdDogUkU6 IFtQMlBTSVBdIFJlOiBISVAgcHJvcyBhbmQgY29ucw0KDQoNCiAgPiBNeSBwcm9ibGVtIGlzIHdo ZW4gSElQIGlzIHVzZWQgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLCANCg0KICA+IG9yIHVzaW5n IHRoZSBzYW1lIGFsZ29yaXRobSB0byBnZW5lcmF0ZSBQZWVyIElELiANCg0KICAgDQoNCiAgSElQ IHJ1bnMgYmVsb3cgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBhbHNvIGJlbG93IHRoZSBwMnAg bGF5ZXIuIA0KDQogIEhJIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBwMnAgbm9kZUlEIG9yIGFwcGxp Y2F0aW9uIGxheWVyIChzdWNoIGFzIFNJUCkgaWRlbnRpZmllcnMsIHN1Y2ggYXMgQW9SLiAgDQoN CiAgIA0KDQogIEhlbnJ5DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgRnJvbTogV2Vp IEdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUB2aXAuc2luYS5jb21dIA0KICBTZW50OiBTdW5kYXks IERlY2VtYmVyIDE2LCAyMDA3IDU6MjUgQU0NCiAgVG86IFAyUFNJUCBNYWlsaW5nIExpc3QNCiAg U3ViamVjdDogRnc6IFtQMlBTSVBdIFJlOiBISVAgcHJvcyBhbmQgY29ucw0KDQogICANCg0KICAg DQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCg0KICBGcm9tOiBXZWkgR2VuZ3l1 IA0KDQogIFRvOiBqZWZmcmV5Lm0uYWhyZW5ob2x6QGJvZWluZy5jb20gOyBzcGVuY2VyQG1jc3It bGFicy5vcmcgOyBQaGlsaXAgTWF0dGhld3MgDQoNCiAgQ2M6IFAyUFNJUCBNYWlsaW5nIExpc3Qg DQoNCiAgU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDE1LCAyMDA3IDEwOjI1IEFNDQoNCiAgU3Vi amVjdDogUmU6IFtQMlBTSVBdIFJlOiBISVAgcHJvcyBhbmQgY29ucw0KDQogICANCg0KICBKZWZm LFNwZW5jZXIsIGFuZCBQaGlsaXAsIA0KDQogICANCg0KICBGaXJzdCwgdGhhbmsgeW91IGFsbCBm b3IgeW91ciBjb3JyZWN0aW9uLg0KDQogICANCg0KICBISVAgbWlnaHQgd29yayB3ZWxsIGFzIFJG QzQ0MjMgZGVmaW5lZC4NCg0KICAgDQoNCiAgTXkgcHJvYmxlbSBpcyB3aGVuIEhJUCBpcyB1c2Vk IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciwgDQoNCiAgb3IgdXNpbmcgdGhlIHNhbWUgYWxnb3Jp dGhtIHRvIGdlbmVyYXRlIFBlZXIgSUQuIA0KDQogICANCg0KICBJZiBISVAtbGlrZSBhbGdvcml0 aG0gaXMgdXNlZCBpbiB0aGUgb3ZlcmxheSB3aGlsZSBISVAgaXMgdXNlZCBiZXR3ZWVuIG5ldHdv cmsgbGF5ZXIgYW5kIHRyYW5zcG9ydCBsYXllciwNCg0KICB0aGUgUGVlciBJRCB3aWxsIHNoYXJl IHRoZSBzYW1lIG5hbWUgc3BhY2Ugd2l0aCBIb3N0IElELg0KDQogIEZvciByZmM0NDIzLCB3aGVu IGEgbm9kZSBoYXZlIG11bHRpcGxlIEhvc3QgSURzLCB0aGV5IG9ubHkgY29zdCBtZW1vcnkgc3Bh Y2VzIGEgbGl0dGxlLg0KDQogIElmIG9uZSBob3N0IGFyZSBwZXJtaXRlZCB0byBoYXZlIG11bHRp cGxlIFBlZXIgSURzIHRoYXQgaGFwcGVuIHRvIGJlbG9uZyB0byBvbmUgb3ZlcmxheSwgDQoNCiAg aXQgd291bGQgaW5jdXIgcG90ZW50aWFsIHJpc2tzIHRvIHRoZSBQMlBTSVAgb3ZlcmxheS4NCg0K ICAgDQoNCiAgQW5kIGl0IHNlZW1zIG5vdCBiZSBjYXBhYmxlIHRvIHRhY2tsZSB0aGlzIGNhc2Ug aW4gUlZTIG9mIEhJUC4gDQoNCiAgSXMgdGhlcmUgc29tZXRoaW5nIHdyb25nPw0KDQogICANCg0K ICBSZWdhcnMsDQoNCiAgIA0KDQogIEdlbmd5dQ0K ------=_NextPart_000_00A3_01C8409B.D048A730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9 Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCjxN RVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMzI0MyIgbmFtZT1HRU5FUkFUT1I+PCEtLVtp ZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0N Cm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kd1w6KiB7DQoJQkVIQVZJ T1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1 bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPg0KPFNUWUxFPg0KPCEtLQ0KIC8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBw YWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4g MS4waW4gMS4yNWluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9T VFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZMaW5rPWJsdWUgbGluaz1ibHVlIGJnQ29sb3I9 d2hpdGU+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5IZW5yeSw8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4mbmJzcDsgPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+SSBhbSB2ZXJ5IGFwcHJlY2lhdGVk IHlvdXIgY29tbWVudHMuIDwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+QW5kIA0K bm8gbmV3IHF1ZXN0aW9ucyBhYm91dCB0aGlzIHRocmVhZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5CdXQgSSBob3BlIHRvIGdldCZuYnNwO2hpbnRzJm5ic3A7 b24gc29tZSBhbHJlYWR5IHJhaXNlZCANCnF1ZXN0aW9ucy4gPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+V291bGQgeW91IHBsZWFzZSBoZWxwIG1lIGNsYXJp ZnkgdGhhdD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5XaGF0 IGlzIHAycCBsYXllcj8gPC9GT05UPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5XaGF0IGRv IHlvdSBtZWFuICJwMnAgDQpsYXllciI/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+SW4gImRyYWZ0LW1hdHRoZXdzLXAycHNpcC1oaXAtaG9wLTAwLiIsd2UgY2Fu IA0Kc2VlJm5ic3A7J3AycC1sYXllcnMnIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7PnRoYXQgaW5jbHVkaW5nIElQdjQgb3IgSVB2NiwgVURQdjQgb3IgVURQ djY/LCBISVAgb3IgRVNQLCBUQ1AgDQpvciBVRFAsIGFuZCBkaXN0cmlidXRlZCBkYXRhYmFzZS4g PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+VGhlICdwMnAg bGF5ZXJzJ2NvbnRhaW4gZml2ZSBsYXllcnMuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7PkkgbmVlZCB0byBrbm93IHRoZSBkaWZmZXJlbmNlJm5ic3A7YmV0d2Vl biAicDJwIGxheWVyIiBhbmQgDQoncDJwIGxheWVycycuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+U28sIEkgc2hhbGwmbmJzcDtzZWUgd2hlcmUgeW91IHB1 dCBISVAgdW5kZXIgcDJwIA0KbGF5ZXIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+SW4gImRyYWZ0LWhhdXRha29ycGktcDJwc2lwLXdpdGgtaGlwLTAxLnR4dCIs IHRoZXJlIGFyZSBmb3VyIA0Kc3VnZ2VzdGlvbnMgaW4gcHJvdG9jb2wgbGF5ZXIgc2NoZW1lLjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pk9ubHkgKGEpIG9m IEZpZ3VyZSAzIGNvbnRhaW5zIEhJUCwgYnV0IEhJUCBpcyBzZXQgb24gdG9wIG9mIA0KUGVlciBw cm90b2NvbC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz53 aGlzdCZuYnNwO3RoZXJlIGlzIG5vIHdvcmRzIG9mICJwMnAgbGF5ZXIiLCBpdCBzZWVtcyB0aGF0 IA0KUGVlciBwcm90b2NvbCBzaG91bGQgYXQgdGhhdCBsYXllci48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz5SZWZlciB0byAmbmJzcDsiZHJhZnQtd2lsbGlzLXAy cHNpcC1jb25jZXB0cy0wNCAtIENvbmNlcHRzIA0KYW5kIFRlcm1pbm9sb2d5IGZvciBQZWVyIHRv IFBlZXIgU0lQIiw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz4iMi4mbmJzcDsgSGlnaCBMZXZlbCBEZXNjcmlwdGlvbjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7PiZuYnNwOyZuYnNwOyBBIFAyUFNJUCBPdmVybGF5IGlzIGEg Y29sbGVjdGlvbiBvZiBub2RlcyANCm9yZ2FuaXplZCBpbiBhIHBlZXItdG8tcGVlcjxCUj4mbmJz cDsmbmJzcDsgZmFzaGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgZW5hYmxpbmcgDQpyZWFsLXRpbWUg Y29tbXVuaWNhdGlvbiB1c2luZyB0aGU8QlI+Jm5ic3A7Jm5ic3A7IFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCANCihTSVApLiZuYnNwOyBDb2xsZWN0aXZlbHksIHRoZSBub2RlcyBpbiB0aGU8 QlI+Jm5ic3A7Jm5ic3A7IG92ZXJsYXkgcHJvdmlkZSBhIA0KZGlzdHJpYnV0ZWQgaW1wbGVtZW50 YXRpb24gb2YgdGhlIGxvY2F0aW9uIHNlcnZpY2U8QlI+Jm5ic3A7Jm5ic3A7IFtSRkMzMjYxXSBm b3IgDQptYXBwaW5nIEFkZHJlc3NlcyBvZiBSZWNvcmQgKEFvUnMpIHRvIENvbnRhY3QgVVJJcy48 QlI+Jm5ic3A7Jm5ic3A7IFRoZXkgYWxzbyANCnByb3ZpZGUgYSB0cmFuc3BvcnQgc2VydmljZSBi eSB3aGljaCBTSVAgbWVzc2FnZXMgY2FuIGJlPEJSPiZuYnNwOyZuYnNwOyANCnRyYW5zcG9ydGVk IGJldHdlZW4gYW55IHR3byBub2RlcyBpbiB0aGUgb3ZlcmxheS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4mbmJzcDsmbmJzcDsgQSBQMlBTSVAgT3ZlcmxheSBj b25zaXN0cyBvZiBvbmUgb3IgbW9yZSBub2RlcyANCmNhbGxlZCBQMlBTSVAgUGVlcnMuPEJSPiZu YnNwOyZuYnNwOyBUaGUgcGVlcnMgaW4gdGhlIG92ZXJsYXkgY29sbGVjdGl2ZWx5IHJ1biBhIA0K ZGlzdHJpYnV0ZWQgZGF0YWJhc2U8QlI+Jm5ic3A7Jm5ic3A7IGFsZ29yaXRobS4mbmJzcDsgVGhp cyBkaXN0cmlidXRlZCBkYXRhYmFzZSANCmFsZ29yaXRobSBhbGxvd3MgZGF0YSB0byBiZTxCUj4m bmJzcDsmbmJzcDsgc3RvcmVkIG9uIHBlZXJzIGFuZCByZXRyaWV2ZWQgaW4gYW4gDQplZmZpY2ll bnQgbWFubmVyLiZuYnNwOyBJdCBtYXkgYWxzbzxCUj4mbmJzcDsmbmJzcDsgZW5zdXJlIHRoYXQg YSBjb3B5IG9mIGEgZGF0YSANCml0ZW0gaXMgc3RvcmVkIG9uIG1vcmUgdGhhbiBvbmUgcGVlciwg c288QlI+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIGxvc3Mgb2YgYSBwZWVyIA0KZG9lcyBub3QgcmVz dWx0IGluIHRoZSBsb3NzIG9mIHRoZSBkYXRhIGl0ZW08QlI+Jm5ic3A7Jm5ic3A7IHRvIHRoZSAN Cm92ZXJsYXkuJm5ic3A7Jm5ic3A7IDwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+ IjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz5VbmZvcnVuYXRlbHksIHRoZXJlIGlzIG5vIGV4cGxpY2l0IA0KZGVmaW5pdGlvbiBvZiAicDJw IGxheWVyIiZuYnNwO2luIHRoZSBJLUQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3Oz5hbHRob3VnaCZuYnNwO3NvJm5ic3A7bWFueSBwZW9wbGUgc2F5Jm5ic3A7 InAycCBsYXllciIgaW4gDQp0aGlzIG1haWxpbmcgbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+RXZlbiBpdCBzZWVtcyB0byBiZSBhIHNpbGx5 IHF1ZXRpb24sICJwMnAgbGF5ZXIiIGlzIHN0aWxsIGEgDQp2YWd1ZSBjb25jZXB0IHdoZW4gcGVv cGxlIHNheSBpdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 Oz5TbywgSSB0aGluayB0aGF0IFdHIG5lZWRzIHRvIG1ha2UmbmJzcDt0aGlzIGJhc2ljIGRlZmlu aXRpb24gDQpjbGVhci4gPC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzs+QmVzdCByZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIz NDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7Pkdlbmd5dSZuYnNwOzwvRElWPjwvRk9OVD4NCjxCTE9DS1FVT1RFIGRpcj1sdHIg DQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxF RlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBw eCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRl NGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZy b206PC9CPiANCiAgPEEgdGl0bGU9aHNpbm5yZWlAYWRvYmUuY29tIGhyZWY9Im1haWx0bzpoc2lu bnJlaUBhZG9iZS5jb20iPkhlbnJ5IA0KICBTaW5ucmVpY2g8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT13ZWln ZW5neXVAdmlwLnNpbmEuY29tIA0KICBocmVmPSJtYWlsdG86d2VpZ2VuZ3l1QHZpcC5zaW5hLmNv bSI+V2VpIEdlbmd5dTwvQT4gOyA8QSB0aXRsZT1wMnBzaXBAaWV0Zi5vcmcgDQogIGhyZWY9Im1h aWx0bzpwMnBzaXBAaWV0Zi5vcmciPlAyUFNJUCBNYWlsaW5nIExpc3Q8L0E+IDwvRElWPg0KICA8 RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IE1vbmRh eSwgRGVjZW1iZXIgMTcsIDIwMDcgNzoyMSBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJFOiBbUDJQU0lQXSBSZTogSElQ IHByb3MgYW5kIA0KICBjb25zPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAz MDc7IHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZP TlQ+PEJSPjwvRElWPg0KICA8RElWIGNsYXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0OzwvU1BB Tj48L0ZPTlQ+PEZPTlQgDQogIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4g TXkgcHJvYmxlbSBpcyB3aGVuJm5ic3A7SElQIGlzIHVzZWQgYXQgDQogIHRoZSBhcHBsaWNhdGlv biBsYXllciwgPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij4mZ3Q7IA0KICBvciB1c2luZyB0aGUgc2FtZSBhbGdvcml0aG0gdG8gZ2VuZXJhdGUgUGVlciBJ RC4gPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5I SVAgDQogIHJ1bnMgYmVsb3cgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBhbHNvIGJlbG93IHRo ZSBwMnAgbGF5ZXIuIA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPkhJIA0KICBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgcDJwIG5vZGVJRCBvciBhcHBs aWNhdGlvbiBsYXllciAoc3VjaCBhcyBTSVApIA0KICBpZGVudGlmaWVycywgc3VjaCBhcyBBb1Iu ICZuYnNwOzwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGVucnk8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8RElWIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVY VC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQgZmFjZT1TaW1TdW4gDQogIHNpemU9 Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgPEhSIHRhYkluZGV4PS0xIGFsaWdu PWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRh aG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0y PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPiBXZWkg DQogIEdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUB2aXAuc2luYS5jb21dIDxCUj48Qj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+IFN1bmRheSwgRGVj ZW1iZXIgMTYsIDIwMDcgNToyNSANCiAgQU08QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hU OiBib2xkIj5Ubzo8L1NQQU4+PC9CPiBQMlBTSVAgTWFpbGluZyANCiAgTGlzdDxCUj48Qj48U1BB TiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlN1YmplY3Q6PC9TUEFOPjwvQj4gRnc6IFtQMlBT SVBdIA0KICBSZTogSElQIHByb3MgYW5kIGNvbnM8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9Q PjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1T dW4gc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdCI+ LS0tLS0gDQogIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD4NCiAgPERJViBzdHlsZT0iZm9udC1jb2xvcjogYmxhY2siPg0KICA8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQiPjxCPjxGT05UIGZhY2U9U2ltU3VuIA0K ICBzaXplPTE+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5 cHQiPkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogIHNpemU9MT48U1BBTiBzdHlsZT0i Rk9OVC1TSVpFOiA5cHQiPiA8QSB0aXRsZT13ZWlnZW5neXVAdmlwLnNpbmEuY29tIA0KICBocmVm PSJtYWlsdG86d2VpZ2VuZ3l1QHZpcC5zaW5hLmNvbSI+V2VpIEdlbmd5dTwvQT4gDQogIDxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Qj48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTE+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdF SUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQiPlRvOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0K ICBzaXplPTE+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB0Ij4gPEEgdGl0bGU9amVmZnJleS5t LmFocmVuaG9sekBib2VpbmcuY29tIA0KICBocmVmPSJtYWlsdG86amVmZnJleS5tLmFocmVuaG9s ekBib2VpbmcuY29tIj5qZWZmcmV5Lm0uYWhyZW5ob2x6QGJvZWluZy5jb208L0E+IA0KICA7IDxB IHRpdGxlPXNwZW5jZXJAbWNzci1sYWJzLm9yZyANCiAgaHJlZj0ibWFpbHRvOnNwZW5jZXJAbWNz ci1sYWJzLm9yZyI+c3BlbmNlckBtY3NyLWxhYnMub3JnPC9BPiA7IDxBIA0KICB0aXRsZT1waGls aXBfbWF0dGhld3NAbWFnbWEuY2EgaHJlZj0ibWFpbHRvOnBoaWxpcF9tYXR0aGV3c0BtYWdtYS5j YSI+UGhpbGlwIA0KICBNYXR0aGV3czwvQT4gPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9U2ltU3Vu IHNpemU9MT48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDlw dCI+Q2M6PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogIHNpemU9MT48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiA5cHQiPiA8QSB0aXRsZT1wMnBzaXBAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpw MnBzaXBAaWV0Zi5vcmciPlAyUFNJUCBNYWlsaW5nIExpc3Q8L0E+IA0KICA8bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+ PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJv bGQ7IEZPTlQtU0laRTogOXB0Ij5TZW50OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICBzaXpl PTE+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB0Ij4gU2F0dXJkYXksIERlY2VtYmVyIDE1LCAy MDA3IDEwOjI1IA0KICBBTTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTE+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQiPlN1YmplY3Q6 PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogIHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVC1TSVpF OiA5cHQiPiBSZTogW1AyUFNJUF0gUmU6IEhJUCBwcm9zIGFuZCANCiAgY29uczxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPkplZmYsU3BlbmNlciwgYW5kIFBoaWxpcCwgDQogIDwv U1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPkZpcnN0LCB0aGFuayB5b3UgYWxsIGZvciB5b3Vy IA0KICBjb3JyZWN0aW9uLjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNp bVN1biBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+SElQIA0KICBtaWdodCB3 b3JrJm5ic3A7d2VsbCBhcyBSRkM0NDIzIGRlZmluZWQuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpw PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2lt U3VuIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij5NeSANCiAgcHJvYmxlbSBpcyB3aGVuJm5ic3A7SElQIGlzIHVzZWQgYXQgdGhlIGFwcGxpY2F0 aW9uIGxheWVyLCANCiAgPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJ Vj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5vciANCiAgdXNpbmcgdGhlIHNhbWUgYWxnb3JpdGhtIHRv IGdlbmVyYXRlIFBlZXIgSUQuIA0KICA8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElW Pg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0z PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPklmIA0KICBI SVAtbGlrZSBhbGdvcml0aG0mbmJzcDtpcyB1c2VkIGluIHRoZSBvdmVybGF5IHdoaWxlJm5ic3A7 SElQIGlzIHVzZWQgYmV0d2VlbiANCiAgbmV0d29yayBsYXllciBhbmQgdHJhbnNwb3J0IGxheWVy LDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+dGhlIA0KICBQZWVyIElEIHdpbGwgc2hhcmUgdGhlIHNhbWUgbmFtZSBzcGFjZSB3 aXRoIEhvc3QgDQogIElELjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXpl PTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Rm9yIA0KICByZmM0NDIzLCZuYnNwO3do ZW4gYSBub2RlIGhhdmUgbXVsdGlwbGUgSG9zdCBJRHMsIHRoZXkmbmJzcDtvbmx5IGNvc3QgbWVt b3J5IA0KICBzcGFjZXMgYSBsaXR0bGUuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJ Vj48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3Vu IHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5JZiANCiAgb25lIGhvc3QgYXJl IHBlcm1pdGVkIHRvIGhhdmUgbXVsdGlwbGUgUGVlciBJRHMgdGhhdCBoYXBwZW4gdG8gYmVsb25n IHRvIG9uZSANCiAgb3ZlcmxheSwgPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+aXQmbmJzcDt3b3VsZCBpbmN1ciBwb3Rl bnRpYWwgcmlza3MgdG8gdGhlIFAyUFNJUCANCiAgb3ZlcmxheS48L1NQQU4+PC9GT05UPjxvOnA+ PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0Ij5BbmQmbmJzcDtpdCBzZWVtcyBub3QgYmUgY2FwYWJsZSB0byB0YWNrbGUgdGhp cyBjYXNlIA0KICBpbiBSVlMmbmJzcDtvZiBISVAuJm5ic3A7PC9TUEFOPjwvRk9OVD48bzpwPjwv bzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 U2ltU3VuIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5JcyANCiAgdGhlcmUg c29tZXRoaW5nIHdyb25nPzwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNp bVN1biBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPlJlZ2Fycyw8L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElW Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5HZW5neXU8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+ PC9QPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00A3_01C8409B.D048A730-- --===============2057287697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2057287697==-- From p2psip-bounces@ietf.org Sun Dec 16 22:28:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J46f0-00035D-CY; Sun, 16 Dec 2007 22:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J46ez-00032f-IK for p2psip@ietf.org; Sun, 16 Dec 2007 22:28:53 -0500 Received: from exprod6og104.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J46ew-0008SQ-Lo for p2psip@ietf.org; Sun, 16 Dec 2007 22:28:53 -0500 Received: from source ([192.150.11.134]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP; Sun, 16 Dec 2007 19:28:47 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBH3QVin019342; Sun, 16 Dec 2007 19:26:31 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBH3SjRC013953; Sun, 16 Dec 2007 19:28:46 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 12:28:45 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Sun, 16 Dec 2007 19:28:38 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE41C@namail5.corp.adobe.com> In-Reply-To: <000001c84058$fabe14c0$da07740a@dellwei> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: HIP pros and cons Thread-Index: AchAWlkqdP68/mHNS3yZLKLEXgXGJgAAVTtw References: <001201c83fd6$58430e80$da07740a@dellwei><24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> From: "Henry Sinnreich" To: "Wei Gengyu" X-OriginalArrivalTime: 17 Dec 2007 03:28:45.0241 (UTC) FILETIME=[EDE49A90:01C8405C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 4db6ecdf6e7461cee1a9e51daa6c3e41 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1903297599==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1903297599== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8405C.EC663363" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8405C.EC663363 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Gengyu,=20 =20 > What is p2p layer? What do you mean "p2p layer"? =20 =20 There is quite clearly exemplified in: =20 =20 ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-matthews-p2psip- id-loc-00.txt=20 =20 =20 ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-baset-p2psip-p2p p-01.txt Please see Fig. 2. =20 One could not explain it any better IMHO. =20 Henry =20 ________________________________ From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Sunday, December 16, 2007 8:59 PM To: Henry Sinnreich Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Re: HIP pros and cons =20 Henry, =20 I am very appreciated your comments. And no new questions about this thread. =20 But I hope to get hints on some already raised questions.=20 Would you please help me clarify that? =20 What is p2p layer? What do you mean "p2p layer"? =20 In "draft-matthews-p2psip-hip-hop-00.",we can see 'p2p-layers'=20 that including IPv4 or IPv6, UDPv4 or UDPv6?, HIP or ESP, TCP or UDP, and distributed database.=20 The 'p2p layers'contain five layers.=20 =20 I need to know the difference between "p2p layer" and 'p2p layers'. So, I shall see where you put HIP under p2p layer. =20 In "draft-hautakorpi-p2psip-with-hip-01.txt", there are four suggestions in protocol layer scheme. Only (a) of Figure 3 contains HIP, but HIP is set on top of Peer protocol. whist there is no words of "p2p layer", it seems that Peer protocol should at that layer. =20 Refer to "draft-willis-p2psip-concepts-04 - Concepts and Terminology for Peer to Peer SIP", "2. High Level Description =20 A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer fashion for the purpose of enabling real-time communication using the Session Initiation Protocol (SIP). Collectively, the nodes in the overlay provide a distributed implementation of the location service [RFC3261] for mapping Addresses of Record (AoRs) to Contact URIs. They also provide a transport service by which SIP messages can be transported between any two nodes in the overlay. =20 A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. The peers in the overlay collectively run a distributed database algorithm. This distributed database algorithm allows data to be stored on peers and retrieved in an efficient manner. It may also ensure that a copy of a data item is stored on more than one peer, so that the loss of a peer does not result in the loss of the data item to the overlay. " =20 Unforunately, there is no explicit definition of "p2p layer" in the I-D although so many people say "p2p layer" in this mailing list. =20 Even it seems to be a silly quetion, "p2p layer" is still a vague concept when people say it. So, I think that WG needs to make this basic definition clear.=20 =20 Best regards, =20 Gengyu=20 ----- Original Message -----=20 From: Henry Sinnreich =20 To: Wei Gengyu ; P2PSIP Mailing List =20 Sent: Monday, December 17, 2007 7:21 AM Subject: RE: [P2PSIP] Re: HIP pros and cons =20 > My problem is when HIP is used at the application layer,=20 > or using the same algorithm to generate Peer ID.=20 =20 HIP runs below the application layer and also below the p2p layer.=20 HI is different from the p2p nodeID or application layer (such as SIP) identifiers, such as AoR. =20 =20 Henry =09 ________________________________ From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Sunday, December 16, 2007 5:25 AM To: P2PSIP Mailing List Subject: Fw: [P2PSIP] Re: HIP pros and cons =20 =20 ----- Original Message -----=20 From: Wei Gengyu =20 To: jeffrey.m.ahrenholz@boeing.com ; spencer@mcsr-labs.org ; Philip Matthews =20 Cc: P2PSIP Mailing List =20 Sent: Saturday, December 15, 2007 10:25 AM Subject: Re: [P2PSIP] Re: HIP pros and cons =20 Jeff,Spencer, and Philip,=20 =20 First, thank you all for your correction. =20 HIP might work well as RFC4423 defined. =20 My problem is when HIP is used at the application layer,=20 or using the same algorithm to generate Peer ID.=20 =20 If HIP-like algorithm is used in the overlay while HIP is used between network layer and transport layer, the Peer ID will share the same name space with Host ID. For rfc4423, when a node have multiple Host IDs, they only cost memory spaces a little. If one host are permited to have multiple Peer IDs that happen to belong to one overlay,=20 it would incur potential risks to the P2PSIP overlay. =20 And it seems not be capable to tackle this case in RVS of HIP.=20 Is there something wrong? =20 Regars, =20 Gengyu ------_=_NextPart_001_01C8405C.EC663363 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Gengyu, 

 

> What is p2p = layer? What do you mean "p2p layer"?

 

 

There is quite clearly exemplified = in:

 

 ftp://ftp.rfc-editor.org/in-notes/internet-drafts/d= raft-matthews-p2psip-id-loc-00.txt

 

 ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-= baset-p2psip-p2pp-01.txt Please see Fig. 2.

 

One could not explain it any better = IMHO.

 

Henry

 

From: Wei = Gengyu [mailto:weigengyu@vip.sina.com]
Sent: Sunday, December = 16, 2007 8:59 PM
To: Henry Sinnreich
Cc: P2PSIP Mailing = List
Subject: Re: [P2PSIP] Re: = HIP pros and cons

 

Henry,

 

I am very appreciated your comments. And no new questions about this = thread.

 

But I hope to get hints on some already raised questions. =

Would you please help me clarify that?

 

What is p2p layer? What do you mean "p2p layer"?

 

In "draft-matthews-p2psip-hip-hop-00.",we can = see 'p2p-layers'

that including IPv4 or IPv6, UDPv4 or UDPv6?, HIP or ESP, TCP or UDP, and distributed database.

The 'p2p layers'contain five layers.

 

I need to know the difference between "p2p layer" and 'p2p layers'.

So, I shall see where you put HIP under p2p layer.

 

In "draft-hautakorpi-p2psip-with-hip-01.txt", there are four = suggestions in protocol layer scheme.

Only (a) of Figure 3 contains HIP, but HIP is set on top of Peer = protocol.

whist there is no words of "p2p layer", it seems that Peer protocol should = at that layer.

 

Refer to  "draft-willis-p2psip-concepts-04 - Concepts and = Terminology for Peer to Peer SIP",

"2.  High Level Description

 

   A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer
   fashion for the purpose of enabling real-time communication = using the
   Session Initiation Protocol (SIP).  Collectively, the = nodes in the
   overlay provide a distributed implementation of the = location service
   [RFC3261] for mapping Addresses of Record (AoRs) to Contact = URIs.
   They also provide a transport service by which SIP messages = can be
   transported between any two nodes in the = overlay.

 

   A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers.
   The peers in the overlay collectively run a distributed = database
   algorithm.  This distributed database algorithm allows = data to be
   stored on peers and retrieved in an efficient manner.  = It may also
   ensure that a copy of a data item is stored on more than = one peer, so
   that the loss of a peer does not result in the loss of the = data item
   to the overlay.   "

 

Unforunately, there is no explicit definition of "p2p layer" in the = I-D

although so many people say "p2p layer" in this mailing = list.

 

Even it seems to be a silly quetion, "p2p layer" is still a vague = concept when people say it.

So, I think that WG needs to make this basic definition clear. =

 

Best regards,

 

Gengyu 

----- Original Message -----

From: Henry Sinnreich =

Sent: Monday, December 17, 2007 7:21 AM

Subject: RE: [P2PSIP] Re: HIP pros and = cons

 

> My problem is when HIP is used at the application layer,

> or using the same algorithm to generate Peer ID. =

 

HIP runs below the application layer and also below the p2p layer. =

HI is different from the p2p nodeID or application layer (such as SIP) identifiers, such as AoR.  

 

Henry

From: Wei = Gengyu [mailto:weigengyu@vip.sina.com]
Sent: Sunday, December = 16, 2007 5:25 AM
To: P2PSIP Mailing = List
Subject: Fw: [P2PSIP] Re: = HIP pros and cons

 

 

----- Original Message -----

From: Wei Gengyu =

Sent: Saturday, December 15, 2007 10:25 = AM

Subject: Re: [P2PSIP] Re: HIP pros and = cons

 

Jeff,Spencer, and Philip,

 

First, thank you all for your correction.

 

HIP might work well as RFC4423 defined.

 

My problem is when HIP is used at the application layer, =

or using the same algorithm to generate Peer ID. =

 

If HIP-like algorithm is used in the overlay while HIP is used = between network layer and transport layer,

the Peer ID will share the same name space with Host = ID.

For rfc4423, when a node have multiple Host IDs, they only cost = memory spaces a little.

If one host are permited to have multiple Peer IDs that happen to belong to = one overlay,

it would incur potential risks to the P2PSIP = overlay.

 

And it seems not be capable to tackle this case in RVS of = HIP. 

Is there something wrong?

 

Regars,

 

Gengyu

------_=_NextPart_001_01C8405C.EC663363-- --===============1903297599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1903297599==-- From p2psip-bounces@ietf.org Mon Dec 17 06:19:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4E0F-0007zN-Ap; Mon, 17 Dec 2007 06:19:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4E0D-0007eq-8F for p2psip@ietf.org; Mon, 17 Dec 2007 06:19:17 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4E08-0003JG-JA for p2psip@ietf.org; Mon, 17 Dec 2007 06:19:15 -0500 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id A0C431DD8E1; Mon, 17 Dec 2007 19:19:07 +0800 (CST) Message-ID: <000e01c8409e$a16f5e60$da07740a@dellwei> From: "Wei Gengyu" To: "Henry Sinnreich" References: <001201c83fd6$58430e80$da07740a@dellwei><24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE41C@namail5.corp.adobe.com> Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Mon, 17 Dec 2007 19:18:55 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.4 (+++) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0475236093==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0475236093== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C840E1.AAF8CAF0" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C840E1.AAF8CAF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVucnksDQoNCk5PLiANCg0KUGxlYXNlIHVzZSB5b3VyIHNlYXJjaGluZyB0b29sIHRvIGxvb2st dXAgInAycCBsYXllciJpbiB0aG9zZSBmaWxlcy4NCkRvIGl0IGJlZm9yZSByZXBseWluZy4NCg0K SSBkaWQgbm90IGZpbmQgIlAyUCBsYXllciIuDQpUaGVyZSBpcyBubyBleHBsaWNpdCBkZWZpbml0 aW9uIG9yIGRlc2NyaXB0aW9uIG9mICJwMnAgbGF5ZXIiDQoNCg0KR2VuZ3l1DQogIC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEhlbnJ5IFNpbm5yZWljaCANCiAgVG86IFdl aSBHZW5neXUgDQogIENjOiBQMlBTSVAgTWFpbGluZyBMaXN0IA0KICBTZW50OiBNb25kYXksIERl Y2VtYmVyIDE3LCAyMDA3IDExOjI4IEFNDQogIFN1YmplY3Q6IFJFOiBbUDJQU0lQXSBSZTogSElQ IHByb3MgYW5kIGNvbnMNCg0KDQogIEdlbmd5dSwgDQoNCiAgIA0KDQogID4gV2hhdCBpcyBwMnAg bGF5ZXI/IFdoYXQgZG8geW91IG1lYW4gInAycCBsYXllciI/DQoNCiAgIA0KDQogICANCg0KICBU aGVyZSBpcyBxdWl0ZSBjbGVhcmx5IGV4ZW1wbGlmaWVkIGluOg0KDQogICANCg0KICAgZnRwOi8v ZnRwLnJmYy1lZGl0b3Iub3JnL2luLW5vdGVzL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0aGV3 cy1wMnBzaXAtaWQtbG9jLTAwLnR4dCANCg0KICAgDQoNCiAgIGZ0cDovL2Z0cC5yZmMtZWRpdG9y Lm9yZy9pbi1ub3Rlcy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmFzZXQtcDJwc2lwLXAycHAtMDEu dHh0IFBsZWFzZSBzZWUgRmlnLiAyLg0KDQogICANCg0KICBPbmUgY291bGQgbm90IGV4cGxhaW4g aXQgYW55IGJldHRlciBJTUhPLg0KDQogICANCg0KICBIZW5yeQ0KDQogICANCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KICBGcm9tOiBXZWkgR2VuZ3l1IFttYWlsdG86d2VpZ2VuZ3l1QHZp cC5zaW5hLmNvbV0gDQogIFNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMTYsIDIwMDcgODo1OSBQTQ0K ICBUbzogSGVucnkgU2lubnJlaWNoDQogIENjOiBQMlBTSVAgTWFpbGluZyBMaXN0DQogIFN1Ympl Y3Q6IFJlOiBbUDJQU0lQXSBSZTogSElQIHByb3MgYW5kIGNvbnMNCg0KICAgDQoNCiAgSGVucnks DQoNCiAgICANCg0KICBJIGFtIHZlcnkgYXBwcmVjaWF0ZWQgeW91ciBjb21tZW50cy4gQW5kIG5v IG5ldyBxdWVzdGlvbnMgYWJvdXQgdGhpcyB0aHJlYWQuDQoNCiAgIA0KDQogIEJ1dCBJIGhvcGUg dG8gZ2V0IGhpbnRzIG9uIHNvbWUgYWxyZWFkeSByYWlzZWQgcXVlc3Rpb25zLiANCg0KICBXb3Vs ZCB5b3UgcGxlYXNlIGhlbHAgbWUgY2xhcmlmeSB0aGF0Pw0KDQogICANCg0KICBXaGF0IGlzIHAy cCBsYXllcj8gV2hhdCBkbyB5b3UgbWVhbiAicDJwIGxheWVyIj8NCg0KICAgDQoNCiAgSW4gImRy YWZ0LW1hdHRoZXdzLXAycHNpcC1oaXAtaG9wLTAwLiIsd2UgY2FuIHNlZSAncDJwLWxheWVycycg DQoNCiAgdGhhdCBpbmNsdWRpbmcgSVB2NCBvciBJUHY2LCBVRFB2NCBvciBVRFB2Nj8sIEhJUCBv ciBFU1AsIFRDUCBvciBVRFAsIGFuZCBkaXN0cmlidXRlZCBkYXRhYmFzZS4gDQoNCiAgVGhlICdw MnAgbGF5ZXJzJ2NvbnRhaW4gZml2ZSBsYXllcnMuIA0KDQogICANCg0KICBJIG5lZWQgdG8ga25v dyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJwMnAgbGF5ZXIiIGFuZCAncDJwIGxheWVycycuDQoN CiAgU28sIEkgc2hhbGwgc2VlIHdoZXJlIHlvdSBwdXQgSElQIHVuZGVyIHAycCBsYXllci4NCg0K ICAgDQoNCiAgSW4gImRyYWZ0LWhhdXRha29ycGktcDJwc2lwLXdpdGgtaGlwLTAxLnR4dCIsIHRo ZXJlIGFyZSBmb3VyIHN1Z2dlc3Rpb25zIGluIHByb3RvY29sIGxheWVyIHNjaGVtZS4NCg0KICBP bmx5IChhKSBvZiBGaWd1cmUgMyBjb250YWlucyBISVAsIGJ1dCBISVAgaXMgc2V0IG9uIHRvcCBv ZiBQZWVyIHByb3RvY29sLg0KDQogIHdoaXN0IHRoZXJlIGlzIG5vIHdvcmRzIG9mICJwMnAgbGF5 ZXIiLCBpdCBzZWVtcyB0aGF0IFBlZXIgcHJvdG9jb2wgc2hvdWxkIGF0IHRoYXQgbGF5ZXIuDQoN CiAgIA0KDQogIFJlZmVyIHRvICAiZHJhZnQtd2lsbGlzLXAycHNpcC1jb25jZXB0cy0wNCAtIENv bmNlcHRzIGFuZCBUZXJtaW5vbG9neSBmb3IgUGVlciB0byBQZWVyIFNJUCIsDQoNCiAgIjIuICBI aWdoIExldmVsIERlc2NyaXB0aW9uDQoNCiAgIA0KDQogICAgIEEgUDJQU0lQIE92ZXJsYXkgaXMg YSBjb2xsZWN0aW9uIG9mIG5vZGVzIG9yZ2FuaXplZCBpbiBhIHBlZXItdG8tcGVlcg0KICAgICBm YXNoaW9uIGZvciB0aGUgcHVycG9zZSBvZiBlbmFibGluZyByZWFsLXRpbWUgY29tbXVuaWNhdGlv biB1c2luZyB0aGUNCiAgICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApLiAgQ29s bGVjdGl2ZWx5LCB0aGUgbm9kZXMgaW4gdGhlDQogICAgIG92ZXJsYXkgcHJvdmlkZSBhIGRpc3Ry aWJ1dGVkIGltcGxlbWVudGF0aW9uIG9mIHRoZSBsb2NhdGlvbiBzZXJ2aWNlDQogICAgIFtSRkMz MjYxXSBmb3IgbWFwcGluZyBBZGRyZXNzZXMgb2YgUmVjb3JkIChBb1JzKSB0byBDb250YWN0IFVS SXMuDQogICAgIFRoZXkgYWxzbyBwcm92aWRlIGEgdHJhbnNwb3J0IHNlcnZpY2UgYnkgd2hpY2gg U0lQIG1lc3NhZ2VzIGNhbiBiZQ0KICAgICB0cmFuc3BvcnRlZCBiZXR3ZWVuIGFueSB0d28gbm9k ZXMgaW4gdGhlIG92ZXJsYXkuDQoNCiAgIA0KDQogICAgIEEgUDJQU0lQIE92ZXJsYXkgY29uc2lz dHMgb2Ygb25lIG9yIG1vcmUgbm9kZXMgY2FsbGVkIFAyUFNJUCBQZWVycy4NCiAgICAgVGhlIHBl ZXJzIGluIHRoZSBvdmVybGF5IGNvbGxlY3RpdmVseSBydW4gYSBkaXN0cmlidXRlZCBkYXRhYmFz ZQ0KICAgICBhbGdvcml0aG0uICBUaGlzIGRpc3RyaWJ1dGVkIGRhdGFiYXNlIGFsZ29yaXRobSBh bGxvd3MgZGF0YSB0byBiZQ0KICAgICBzdG9yZWQgb24gcGVlcnMgYW5kIHJldHJpZXZlZCBpbiBh biBlZmZpY2llbnQgbWFubmVyLiAgSXQgbWF5IGFsc28NCiAgICAgZW5zdXJlIHRoYXQgYSBjb3B5 IG9mIGEgZGF0YSBpdGVtIGlzIHN0b3JlZCBvbiBtb3JlIHRoYW4gb25lIHBlZXIsIHNvDQogICAg IHRoYXQgdGhlIGxvc3Mgb2YgYSBwZWVyIGRvZXMgbm90IHJlc3VsdCBpbiB0aGUgbG9zcyBvZiB0 aGUgZGF0YSBpdGVtDQogICAgIHRvIHRoZSBvdmVybGF5LiAgICINCg0KICAgDQoNCiAgVW5mb3J1 bmF0ZWx5LCB0aGVyZSBpcyBubyBleHBsaWNpdCBkZWZpbml0aW9uIG9mICJwMnAgbGF5ZXIiIGlu IHRoZSBJLUQNCg0KICBhbHRob3VnaCBzbyBtYW55IHBlb3BsZSBzYXkgInAycCBsYXllciIgaW4g dGhpcyBtYWlsaW5nIGxpc3QuDQoNCiAgIA0KDQogIEV2ZW4gaXQgc2VlbXMgdG8gYmUgYSBzaWxs eSBxdWV0aW9uLCAicDJwIGxheWVyIiBpcyBzdGlsbCBhIHZhZ3VlIGNvbmNlcHQgd2hlbiBwZW9w bGUgc2F5IGl0Lg0KDQogIFNvLCBJIHRoaW5rIHRoYXQgV0cgbmVlZHMgdG8gbWFrZSB0aGlzIGJh c2ljIGRlZmluaXRpb24gY2xlYXIuIA0KDQogICANCg0KICBCZXN0IHJlZ2FyZHMsDQoNCiAgIA0K DQogIEdlbmd5dSANCg0KICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQoNCiAgICBG cm9tOiBIZW5yeSBTaW5ucmVpY2ggDQoNCiAgICBUbzogV2VpIEdlbmd5dSA7IFAyUFNJUCBNYWls aW5nIExpc3QgDQoNCiAgICBTZW50OiBNb25kYXksIERlY2VtYmVyIDE3LCAyMDA3IDc6MjEgQU0N Cg0KICAgIFN1YmplY3Q6IFJFOiBbUDJQU0lQXSBSZTogSElQIHByb3MgYW5kIGNvbnMNCg0KICAg ICANCg0KICAgID4gTXkgcHJvYmxlbSBpcyB3aGVuIEhJUCBpcyB1c2VkIGF0IHRoZSBhcHBsaWNh dGlvbiBsYXllciwgDQoNCiAgICA+IG9yIHVzaW5nIHRoZSBzYW1lIGFsZ29yaXRobSB0byBnZW5l cmF0ZSBQZWVyIElELiANCg0KICAgICANCg0KICAgIEhJUCBydW5zIGJlbG93IHRoZSBhcHBsaWNh dGlvbiBsYXllciBhbmQgYWxzbyBiZWxvdyB0aGUgcDJwIGxheWVyLiANCg0KICAgIEhJIGlzIGRp ZmZlcmVudCBmcm9tIHRoZSBwMnAgbm9kZUlEIG9yIGFwcGxpY2F0aW9uIGxheWVyIChzdWNoIGFz IFNJUCkgaWRlbnRpZmllcnMsIHN1Y2ggYXMgQW9SLiAgDQoNCiAgICAgDQoNCiAgICBIZW5yeQ0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIEZyb206IFdlaSBHZW5neXUgW21haWx0bzp3 ZWlnZW5neXVAdmlwLnNpbmEuY29tXSANCiAgICBTZW50OiBTdW5kYXksIERlY2VtYmVyIDE2LCAy MDA3IDU6MjUgQU0NCiAgICBUbzogUDJQU0lQIE1haWxpbmcgTGlzdA0KICAgIFN1YmplY3Q6IEZ3 OiBbUDJQU0lQXSBSZTogSElQIHByb3MgYW5kIGNvbnMNCg0KICAgICANCg0KICAgICANCg0KICAg IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQoNCiAgICBGcm9tOiBXZWkgR2VuZ3l1IA0K DQogICAgVG86IGplZmZyZXkubS5haHJlbmhvbHpAYm9laW5nLmNvbSA7IHNwZW5jZXJAbWNzci1s YWJzLm9yZyA7IFBoaWxpcCBNYXR0aGV3cyANCg0KICAgIENjOiBQMlBTSVAgTWFpbGluZyBMaXN0 IA0KDQogICAgU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDE1LCAyMDA3IDEwOjI1IEFNDQoNCiAg ICBTdWJqZWN0OiBSZTogW1AyUFNJUF0gUmU6IEhJUCBwcm9zIGFuZCBjb25zDQoNCiAgICAgDQoN CiAgICBKZWZmLFNwZW5jZXIsIGFuZCBQaGlsaXAsIA0KDQogICAgIA0KDQogICAgRmlyc3QsIHRo YW5rIHlvdSBhbGwgZm9yIHlvdXIgY29ycmVjdGlvbi4NCg0KICAgICANCg0KICAgIEhJUCBtaWdo dCB3b3JrIHdlbGwgYXMgUkZDNDQyMyBkZWZpbmVkLg0KDQogICAgIA0KDQogICAgTXkgcHJvYmxl bSBpcyB3aGVuIEhJUCBpcyB1c2VkIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciwgDQoNCiAgICBv ciB1c2luZyB0aGUgc2FtZSBhbGdvcml0aG0gdG8gZ2VuZXJhdGUgUGVlciBJRC4gDQoNCiAgICAg DQoNCiAgICBJZiBISVAtbGlrZSBhbGdvcml0aG0gaXMgdXNlZCBpbiB0aGUgb3ZlcmxheSB3aGls ZSBISVAgaXMgdXNlZCBiZXR3ZWVuIG5ldHdvcmsgbGF5ZXIgYW5kIHRyYW5zcG9ydCBsYXllciwN Cg0KICAgIHRoZSBQZWVyIElEIHdpbGwgc2hhcmUgdGhlIHNhbWUgbmFtZSBzcGFjZSB3aXRoIEhv c3QgSUQuDQoNCiAgICBGb3IgcmZjNDQyMywgd2hlbiBhIG5vZGUgaGF2ZSBtdWx0aXBsZSBIb3N0 IElEcywgdGhleSBvbmx5IGNvc3QgbWVtb3J5IHNwYWNlcyBhIGxpdHRsZS4NCg0KICAgIElmIG9u ZSBob3N0IGFyZSBwZXJtaXRlZCB0byBoYXZlIG11bHRpcGxlIFBlZXIgSURzIHRoYXQgaGFwcGVu IHRvIGJlbG9uZyB0byBvbmUgb3ZlcmxheSwgDQoNCiAgICBpdCB3b3VsZCBpbmN1ciBwb3RlbnRp YWwgcmlza3MgdG8gdGhlIFAyUFNJUCBvdmVybGF5Lg0KDQogICAgIA0KDQogICAgQW5kIGl0IHNl ZW1zIG5vdCBiZSBjYXBhYmxlIHRvIHRhY2tsZSB0aGlzIGNhc2UgaW4gUlZTIG9mIEhJUC4gDQoN CiAgICBJcyB0aGVyZSBzb21ldGhpbmcgd3Jvbmc/DQoNCiAgICAgDQoNCiAgICBSZWdhcnMsDQoN CiAgICAgDQoNCiAgICBHZW5neXUNCg== ------=_NextPart_000_000B_01C840E1.AAF8CAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVp dj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0K PE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zMjQzIiBuYW1lPUdFTkVSQVRPUj48IS0t W2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0K fQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQp3XDoqIHsNCglCRUhB VklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJQkVIQVZJT1I6IHVybCgjZGVm YXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+PG86U21hcnRUYWdUeXBlIG5hbWU9 IlBlcnNvbk5hbWUiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT4N CnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L1NUWUxFPg0KPCFbZW5k aWZdLS0+DQo8U1RZTEU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQog cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFy aWFsOw0KCWNvbG9yOm5hdnk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFn ZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEu MGluIDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvU1RZ TEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1ibHVlIGxpbms9Ymx1ZSBiZ0NvbG9yPXdo aXRlPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkhlbnJ5LDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Tk8u IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+UGxlYXNlIHVzZSB5b3VyIHNlYXJjaGluZyB0b29sIHRvIGxvb2stdXAgInAycCANCmxheWVy ImluIHRob3NlIGZpbGVzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj5EbyBpdCBiZWZvcmUgcmVwbHlpbmcuPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5JIGRpZCBub3QgZmluZCAiUDJQ IGxheWVyIi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+VGhlcmUgaXMgbm8gZXhwbGljaXQgZGVmaW5pdGlvbiBvciBkZXNjcmlwdGlvbiBvZiAi cDJwIA0KbGF5ZXIiPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYj MjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+R2VuZ3l1PC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0 ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4t TEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDog MHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNl NGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBmb250LWNvbG9yOiBibGFjayI+PEI+ RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1oc2lubnJlaUBhZG9iZS5jb20gaHJlZj0ibWFpbHRvOmhz aW5ucmVpQGFkb2JlLmNvbSI+SGVucnkgDQogIFNpbm5yZWljaDwvQT4gPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPXdl aWdlbmd5dUB2aXAuc2luYS5jb20gDQogIGhyZWY9Im1haWx0bzp3ZWlnZW5neXVAdmlwLnNpbmEu Y29tIj5XZWkgR2VuZ3l1PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9cDJwc2lwQGlldGYub3JnIA0KICBocmVm PSJtYWlsdG86cDJwc2lwQGlldGYub3JnIj5QMlBTSVAgTWFpbGluZyBMaXN0PC9BPiA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBN b25kYXksIERlY2VtYmVyIDE3LCAyMDA3IDExOjI4IA0KQU08L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSRTogW1AyUFNJUF0g UmU6IEhJUCBwcm9zIGFuZCANCiAgY29uczwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJ ViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3Vu IHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+R2VuZ3l1LCZuYnNwOzxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0OzwvU1BBTj48L0ZPTlQ+IA0KICBXaGF0IGlz IHAycCBsYXllcj8gV2hhdCBkbyB5b3UgbWVhbiAicDJwIGxheWVyIj88Rk9OVCANCiAgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJyI+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhlcmUgaXMgcXVpdGUgDQogIGNsZWFybHkgZXhl bXBsaWZpZWQgaW46PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8QSANCiAgaHJl Zj0iZnRwOi8vZnRwLnJmYy1lZGl0b3Iub3JnL2luLW5vdGVzL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1tYXR0aGV3cy1wMnBzaXAtaWQtbG9jLTAwLnR4dCI+ZnRwOi8vZnRwLnJmYy1lZGl0b3Iub3Jn L2luLW5vdGVzL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0aGV3cy1wMnBzaXAtaWQtbG9jLTAw LnR4dDwvQT4gDQogIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PEEgDQogIGhy ZWY9ImZ0cDovL2Z0cC5yZmMtZWRpdG9yLm9yZy9pbi1ub3Rlcy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtYmFzZXQtcDJwc2lwLXAycHAtMDEudHh0Ij5mdHA6Ly9mdHAucmZjLWVkaXRvci5vcmcvaW4t bm90ZXMvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJhc2V0LXAycHNpcC1wMnBwLTAxLnR4dDwvQT4g DQogIFBsZWFzZSBzZWUgRmlnLiAyLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+T25lIGNv dWxkIG5vdCBleHBsYWluIA0KICBpdCBhbnkgYmV0dGVyIElNSE8uPG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1J TFk6IEFyaWFsIj5IZW5yeTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8RElWIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQg DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPg0KICA8SFIgdGFiSW5k ZXg9LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogIDwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogVGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICBmYWNlPVRh aG9tYSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRh aG9tYSI+IFdlaSANCiAgR2VuZ3l1IFttYWlsdG86d2VpZ2VuZ3l1QHZpcC5zaW5hLmNvbV0gPEJS PjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlNlbnQ6PC9TUEFOPjwvQj4g U3VuZGF5LCBEZWNlbWJlciAxNiwgMjAwNyA4OjU5IA0KICBQTTxCUj48Qj48U1BBTiBzdHlsZT0i Rk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IDxzdDE6UGVyc29uTmFtZSANCiAgdzpz dD0ib24iPkhlbnJ5IFNpbm5yZWljaDwvc3QxOlBlcnNvbk5hbWU+PEJSPjxCPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkNjOjwvU1BBTj48L0I+IFAyUFNJUCBNYWlsaW5nIExp c3Q8QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQ QU4+PC9CPiBSZTogW1AyUFNJUF0gUmU6IEhJUCBwcm9zIGFuZCANCiAgY29uczwvU1BBTj48L0ZP TlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJ Vj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05U PjwvUD4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNp emU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+SGVucnksPC9TUEFOPjwvRk9O VD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElW Pg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0z PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsgPC9TUEFOPjwvRk9OVD48 Rk9OVCANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJ Vj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9 Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5JIGFtIA0KICB2ZXJ5IGFwcHJlY2lhdGVk IHlvdXIgY29tbWVudHMuIEFuZCBubyBuZXcgcXVlc3Rpb25zIGFib3V0IHRoaXMgDQogIHRocmVh ZC48L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPkJ1dCANCiAg SSBob3BlIHRvIGdldCZuYnNwO2hpbnRzJm5ic3A7b24gc29tZSBhbHJlYWR5IHJhaXNlZCBxdWVz dGlvbnMuIA0KICA8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQ QU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQi PldvdWxkIHlvdSBwbGVhc2UgaGVscCBtZSBjbGFyaWZ5IA0KICB0aGF0PzwvU1BBTj48L0ZPTlQ+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGltZXMgTmV3IFJvbWFuJyI+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXpl PTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+V2hhdCANCiAgaXMgcDJwIGxheWVyPyBX aGF0IGRvIHlvdSBtZWFuICJwMnAgbGF5ZXIiPzwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcg Um9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElW Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQiPkluIA0KICAiZHJhZnQtbWF0dGhld3MtcDJwc2lwLWhpcC1o b3AtMDAuIix3ZSBjYW4gc2VlJm5ic3A7J3AycC1sYXllcnMnIA0KICA8L1NQQU4+PC9GT05UPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQog IDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+dGhhdCANCiAgaW5jbHVkaW5nIElQdjQgb3IgSVB2 NiwgVURQdjQgb3IgVURQdjY/LCBISVAgb3IgRVNQLCBUQ1Agb3IgVURQLCBhbmQgDQogIGRpc3Ry aWJ1dGVkIGRhdGFiYXNlLiA8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+VGhlIA0KICAncDJwIGxheWVycydjb250YWluIGZpdmUgbGF5ZXJzLiA8L1NQQU4+PC9GT05U PjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwv RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwv UD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3Vu IHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5JIA0KICBuZWVkIHRvIGtub3cg dGhlIGRpZmZlcmVuY2UmbmJzcDtiZXR3ZWVuICJwMnAgbGF5ZXIiIGFuZCAncDJwIA0KICBsYXll cnMnLjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiANCiAg c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+PG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9U2ltU3VuIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5TbywgDQogIEkg c2hhbGwmbmJzcDtzZWUgd2hlcmUgeW91IHB1dCBISVAgdW5kZXIgcDJwIGxheWVyLjwvU1BBTj48 L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1T aW1TdW4gc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPkluIA0KICAiZHJhZnQt aGF1dGFrb3JwaS1wMnBzaXAtd2l0aC1oaXAtMDEudHh0IiwgdGhlcmUgYXJlIGZvdXIgc3VnZ2Vz dGlvbnMgaW4gDQogIHByb3RvY29sIGxheWVyIHNjaGVtZS48L1NQQU4+PC9GT05UPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+T25seSANCiAgKGEpIG9mIEZpZ3VyZSAzIGNvbnRhaW5zIEhJ UCwgYnV0IEhJUCBpcyBzZXQgb24gdG9wIG9mIFBlZXIgDQogIHByb3RvY29sLjwvU1BBTj48L0ZP TlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJ Vj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9 Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+d2hpc3QmbmJzcDt0aGVyZSBpcyBu byB3b3JkcyBvZiAicDJwIGxheWVyIiwgaXQgc2VlbXMgDQogIHRoYXQgUGVlciBwcm90b2NvbCBz aG91bGQgYXQgdGhhdCBsYXllci48L1NQQU4+PC9GT05UPjxGT05UIA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n Ij48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+ Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdCI+UmVmZXIgdG8gJm5ic3A7ImRyYWZ0LXdpbGxpcy1wMnBzaXAtY29u Y2VwdHMtMDQgLSANCiAgQ29uY2VwdHMgYW5kIFRlcm1pbm9sb2d5IGZvciBQZWVyIHRvIFBlZXIg U0lQIiw8L1NQQU4+PC9GT05UPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4i Mi4mbmJzcDsgSGlnaCBMZXZlbCBEZXNjcmlwdGlvbjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsmbmJzcDsgQSBQMlBTSVAgT3Zlcmxh eSBpcyBhIGNvbGxlY3Rpb24gb2Ygbm9kZXMgDQogIG88c3QxOlBlcnNvbk5hbWUgdzpzdD0ib24i PnJnPC9zdDE6UGVyc29uTmFtZT5hbml6ZWQgaW4gYSANCiAgcGVlci10by1wZWVyPEJSPiZuYnNw OyZuYnNwOyBmYXNoaW9uIGZvciB0aGUgcHVycG9zZSBvZiBlbmFibGluZyByZWFsLXRpbWUgDQog IGNvbW11bmljYXRpb24gdXNpbmcgdGhlPEJSPiZuYnNwOyZuYnNwOyBTZXNzaW9uIEluaXRpYXRp b24gUHJvdG9jb2wgDQogIChTSVApLiZuYnNwOyBDb2xsZWN0aXZlbHksIHRoZSBub2RlcyBpbiB0 aGU8QlI+Jm5ic3A7Jm5ic3A7IG92ZXJsYXkgcHJvdmlkZSBhIA0KICBkaXN0cmlidXRlZCBpbXBs ZW1lbnRhdGlvbiBvZiB0aGUgbG9jYXRpb24gc2VydmljZTxCUj4mbmJzcDsmbmJzcDsgW1JGQzMy NjFdIA0KICBmb3IgbWFwcGluZyBBZGRyZXNzZXMgb2YgUmVjb3JkIChBb1JzKSB0byBDb250YWN0 IFVSSXMuPEJSPiZuYnNwOyZuYnNwOyBUaGV5IA0KICBhbHNvIHByb3ZpZGUgYSB0cmFuc3BvcnQg c2VydmljZSBieSB3aGljaCBTSVAgbWVzc2FnZXMgY2FuIGJlPEJSPiZuYnNwOyZuYnNwOyANCiAg dHJhbnNwb3J0ZWQgYmV0d2VlbiBhbnkgdHdvIG5vZGVzIGluIHRoZSBvdmVybGF5LjwvU1BBTj48 L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJG T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1T aW1TdW4gc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDsmbmJz cDsgQSBQMlBTSVAgT3ZlcmxheSBjb25zaXN0cyBvZiBvbmUgb3IgbW9yZSANCiAgbm9kZXMgY2Fs bGVkIFAyUFNJUCBQZWVycy48QlI+Jm5ic3A7Jm5ic3A7IFRoZSBwZWVycyBpbiB0aGUgb3Zlcmxh eSANCiAgY29sbGVjdGl2ZWx5IHJ1biBhIGRpc3RyaWJ1dGVkIGRhdGFiYXNlPEJSPiZuYnNwOyZu YnNwOyBhbGdvcml0aG0uJm5ic3A7IFRoaXMgDQogIGRpc3RyaWJ1dGVkIGRhdGFiYXNlIGFsZ29y aXRobSBhbGxvd3MgZGF0YSB0byBiZTxCUj4mbmJzcDsmbmJzcDsgc3RvcmVkIG9uIA0KICBwZWVy cyBhbmQgcmV0cmlldmVkIGluIGFuIGVmZmljaWVudCBtYW5uZXIuJm5ic3A7IEl0IG1heSBhbHNv PEJSPiZuYnNwOyZuYnNwOyANCiAgZW5zdXJlIHRoYXQgYSBjb3B5IG9mIGEgZGF0YSBpdGVtIGlz IHN0b3JlZCBvbiBtb3JlIHRoYW4gb25lIHBlZXIsIA0KICBzbzxCUj4mbmJzcDsmbmJzcDsgdGhh dCB0aGUgbG9zcyBvZiBhIHBlZXIgZG9lcyBub3QgcmVzdWx0IGluIHRoZSBsb3NzIG9mIHRoZSAN CiAgZGF0YSBpdGVtPEJSPiZuYnNwOyZuYnNwOyB0byB0aGUgb3ZlcmxheS4mbmJzcDsmbmJzcDsg IjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5V bmZvcnVuYXRlbHksIHRoZXJlIGlzIG5vIGV4cGxpY2l0IGRlZmluaXRpb24gb2YgInAycCANCiAg bGF5ZXIiJm5ic3A7aW4gdGhlIEktRDwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+ PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+YWx0aG91Z2gmbmJzcDtzbyZuYnNwO21hbnkgcGVvcGxlIHNheSZuYnNwOyJw MnAgbGF5ZXIiIA0KICBpbiB0aGlzIG1haWxpbmcgbGlzdC48L1NQQU4+PC9GT05UPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6 ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPkV2ZW4gDQogIGl0IHNlZW1zIHRvIGJl IGEgc2lsbHkgcXVldGlvbiwgInAycCBsYXllciIgaXMgc3RpbGwgYSB2YWd1ZSBjb25jZXB0IHdo ZW4gDQogIHBlb3BsZSBzYXkgaXQuPC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPlNvLCANCiAgSSB0aGluayB0aGF0IFdHIG5lZWRzIHRvIG1ha2UmbmJzcDt0aGlzIGJh c2ljIGRlZmluaXRpb24gY2xlYXIuIA0KICA8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h biciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcg Um9tYW4nIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElW Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQiPkJlc3QgDQogIHJlZ2FyZHMsPC9TUEFOPjwvRk9OVD48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGlt ZXMgTmV3IFJvbWFuJyI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+R2VuZ3l1Jm5ic3A7PG86cD48L286cD48 L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPEJMT0NLUVVPVEUgDQogIHN0eWxlPSJCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1 bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBpbjsgTUFSR0lOOiA1 cHQgMGluIDVwdCAzLjc1cHQ7IEJPUkRFUi1MRUZUOiBibGFjayAxLjVwdCBzb2xpZDsgUEFERElO Ry1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgIDxESVY+DQogICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9MT48U1BBTiANCiAgICBz dHlsZT0iRk9OVC1TSVpFOiA5cHQiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogICAg PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8RElWIHN0eWxlPSJmb250 LWNvbG9yOiBibGFjayI+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJCQUNLR1JPVU5E OiAjZTRlNGU0Ij48Qj48Rk9OVCBmYWNlPVNpbVN1biANCiAgICBzaXplPTE+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDlwdCI+RnJvbTo8L1NQQU4+PC9G T05UPjwvQj48Rk9OVCANCiAgICBzaXplPTE+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB0Ij4g PEEgdGl0bGU9aHNpbm5yZWlAYWRvYmUuY29tIA0KICAgIGhyZWY9Im1haWx0bzpoc2lubnJlaUBh ZG9iZS5jb20iPkhlbnJ5IFNpbm5yZWljaDwvQT4gDQogICAgPG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9O VCBmYWNlPVNpbVN1biBzaXplPTE+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xk OyBGT05ULVNJWkU6IDlwdCI+VG86PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgc2l6ZT0x PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdCI+IDxBIHRpdGxlPXdlaWdlbmd5dUB2aXAuc2lu YS5jb20gDQogICAgaHJlZj0ibWFpbHRvOndlaWdlbmd5dUB2aXAuc2luYS5jb20iPldlaSBHZW5n eXU8L0E+IDsgPEEgDQogICAgdGl0bGU9cDJwc2lwQGlldGYub3JnIGhyZWY9Im1haWx0bzpwMnBz aXBAaWV0Zi5vcmciPlAyUFNJUCBNYWlsaW5nIExpc3Q8L0E+IA0KICAgIDxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEI+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdI VDogYm9sZDsgRk9OVC1TSVpFOiA5cHQiPlNlbnQ6PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQog ICAgc2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdCI+IE1vbmRheSwgRGVjZW1iZXIg MTcsIDIwMDcgNzoyMSANCiAgICBBTTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+ DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1TaW1TdW4g c2l6ZT0xPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5 cHQiPlN1YmplY3Q6PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgc2l6ZT0xPjxTUEFOIHN0 eWxlPSJGT05ULVNJWkU6IDlwdCI+IFJFOiBbUDJQU0lQXSBSZTogSElQIHByb3MgYW5kIA0KICAg IGNvbnM8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxT UEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BB TiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6 IEFyaWFsIj4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgICBzaXplPTI+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+IE15IHByb2JsZW0gaXMgd2hlbiZuYnNwO0hJUCBpcyB1c2VkIGF0 IA0KICAgIHRoZSBhcHBsaWNhdGlvbiBsYXllciwgPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwv UD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFO IA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgb3IgdXNpbmcgdGhlIHNhbWUgYWxn b3JpdGhtIHRvIGdlbmVyYXRlIFBlZXIgDQogICAgSUQuIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBz aXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+SElQIHJ1bnMgYmVsb3cg dGhlIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBhbHNvIGJlbG93IA0KICAgIHRoZSBwMnAgbGF5ZXIu IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5ISSAN CiAgICBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgcDJwIG5vZGVJRCBvciBhcHBsaWNhdGlvbiBsYXll ciAoc3VjaCBhcyBTSVApIA0KICAgIGlkZW50aWZpZXJzLCBzdWNoIGFzIEFvUi4gJm5ic3A7PC9T UEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkhlbnJ5PG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgICA8RElWPg0KICAgIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJU RVhULUFMSUdOOiBjZW50ZXIiIGFsaWduPWNlbnRlcj48Rk9OVCANCiAgICBmYWNlPVNpbVN1biBz aXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+DQogICAgPEhSIHRhYkluZGV4PS0x IGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICAgIDwvU1BBTj48L0ZPTlQ+PC9E SVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgICBmYWNl PVRhaG9tYSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IFRhaG9tYSI+IFdlaSANCiAgICBHZW5neXUgW21haWx0bzp3ZWlnZW5neXVAdmlwLnNpbmEuY29t XSA8QlI+PEI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BB Tj48L0I+IFN1bmRheSwgRGVjZW1iZXIgMTYsIDIwMDcgNToyNSANCiAgICBBTTxCUj48Qj48U1BB TiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IFAyUFNJUCBNYWlsaW5n IA0KICAgIExpc3Q8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0 OjwvU1BBTj48L0I+IEZ3OiBbUDJQU0lQXSANCiAgICBSZTogSElQIHByb3MgYW5kIGNvbnM8L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8RElWPg0KICAgIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogICAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48 L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1 biBzaXplPTE+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogOXB0Ij4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAg PERJViBzdHlsZT0iZm9udC1jb2xvcjogYmxhY2siPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNCI+PEI+PEZPTlQgZmFjZT1TaW1TdW4gDQogICAgc2l6 ZT0xPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQi PkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgc2l6ZT0xPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDlwdCI+IDxBIHRpdGxlPXdlaWdlbmd5dUB2aXAuc2luYS5jb20gDQogICAgaHJl Zj0ibWFpbHRvOndlaWdlbmd5dUB2aXAuc2luYS5jb20iPldlaSBHZW5neXU8L0E+IA0KICAgIDxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIA0KICAgIHN0eWxl PSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQiPlRvOjwvU1BBTj48L0ZPTlQ+PC9C PjxGT05UIA0KICAgIHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPiA8QSB0aXRs ZT1qZWZmcmV5Lm0uYWhyZW5ob2x6QGJvZWluZy5jb20gDQogICAgaHJlZj0ibWFpbHRvOmplZmZy ZXkubS5haHJlbmhvbHpAYm9laW5nLmNvbSI+amVmZnJleS5tLmFocmVuaG9sekBib2VpbmcuY29t PC9BPiANCiAgICA7IDxBIHRpdGxlPXNwZW5jZXJAbWNzci1sYWJzLm9yZyANCiAgICBocmVmPSJt YWlsdG86c3BlbmNlckBtY3NyLWxhYnMub3JnIj5zcGVuY2VyQG1jc3ItbGFicy5vcmc8L0E+IDsg PEEgDQogICAgdGl0bGU9cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIGhyZWY9Im1haWx0bzpwaGls aXBfbWF0dGhld3NAbWFnbWEuY2EiPlBoaWxpcCANCiAgICBNYXR0aGV3czwvQT4gPG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Qj48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTE+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt V0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDlwdCI+Q2M6PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQg DQogICAgc2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdCI+IDxBIHRpdGxlPXAycHNp cEBpZXRmLm9yZyANCiAgICBocmVmPSJtYWlsdG86cDJwc2lwQGlldGYub3JnIj5QMlBTSVAgTWFp bGluZyBMaXN0PC9BPiANCiAgICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0K ICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9U2ltU3VuIHNp emU9MT48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0 Ij5TZW50OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgIHNpemU9MT48U1BBTiBzdHlsZT0i Rk9OVC1TSVpFOiA5cHQiPiBTYXR1cmRheSwgRGVjZW1iZXIgMTUsIDIwMDcgMTA6MjUgDQogICAg QU08bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9MT48U1BBTiANCiAgICBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0Ij5TdWJqZWN0OjwvU1BBTj48 L0ZPTlQ+PC9CPjxGT05UIA0KICAgIHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQi PiBSZTogW1AyUFNJUF0gUmU6IEhJUCBwcm9zIGFuZCANCiAgICBjb25zPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD48L0RJVj48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8 RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQ QU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+SmVmZixTcGVuY2VyLCBhbmQgUGhpbGlw LCANCiAgICA8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxESVY+DQog ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiANCiAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 U2ltU3VuIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5GaXJzdCwg dGhhbmsgeW91IGFsbCBmb3IgeW91ciANCiAgICBjb3JyZWN0aW9uLjwvU1BBTj48L0ZPTlQ+PG86 cD48L286cD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAg ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPkhJUCBtaWdodCB3b3JrJm5ic3A7d2VsbCBhcyBSRkM0 NDIzIA0KICAgIGRlZmluZWQuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAg ICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+ PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+TXkg DQogICAgcHJvYmxlbSBpcyB3aGVuJm5ic3A7SElQIGlzIHVzZWQgYXQgdGhlIGFwcGxpY2F0aW9u IGxheWVyLCANCiAgICA8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxE SVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5vciANCiAgICB1c2luZyB0aGUgc2FtZSBhbGdvcml0 aG0gdG8gZ2VuZXJhdGUgUGVlciBJRC4gDQogICAgPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwv UD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNp bVN1biBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86 cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+SWYgDQogICAgSElQLWxpa2UgYWxnb3JpdGhtJm5ic3A7aXMgdXNlZCBpbiB0aGUg b3ZlcmxheSB3aGlsZSZuYnNwO0hJUCBpcyB1c2VkIA0KICAgIGJldHdlZW4gbmV0d29yayBsYXll ciBhbmQgdHJhbnNwb3J0IA0KbGF5ZXIsPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJ Vj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBz aXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+dGhlIFBlZXIgSUQgd2ls bCBzaGFyZSB0aGUgc2FtZSBuYW1lIHNwYWNlIHdpdGggSG9zdCANCiAgICBJRC48L1NQQU4+PC9G T05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPERJVj4NCiAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQiPkZvciByZmM0NDIzLCZuYnNwO3doZW4gYSBub2RlIGhhdmUgbXVs dGlwbGUgSG9zdCANCiAgICBJRHMsIHRoZXkmbmJzcDtvbmx5IGNvc3QgbWVtb3J5IHNwYWNlcyBh IA0KICAgIGxpdHRsZS48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPjwvRElWPg0K ICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9 Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5JZiANCiAgICBvbmUgaG9zdCBhcmUgcGVy bWl0ZWQgdG8gaGF2ZSBtdWx0aXBsZSBQZWVyIElEcyB0aGF0IGhhcHBlbiB0byBiZWxvbmcgdG8g b25lIA0KICAgIG92ZXJsYXksIDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQog ICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0y PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPml0Jm5ic3A7d291bGQgaW5jdXIg cG90ZW50aWFsIHJpc2tzIHRvIHRoZSBQMlBTSVAgDQogICAgb3ZlcmxheS48L1NQQU4+PC9GT05U PjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+ DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiAN CiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5BbmQmbmJzcDtpdCBzZWVtcyBub3QgYmUgY2Fw YWJsZSB0byB0YWNrbGUgdGhpcyBjYXNlIA0KICAgIGluIFJWUyZuYnNwO29mIEhJUC4mbmJzcDs8 L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mj48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0Ij5JcyANCiAgICB0aGVyZSBzb21ldGhpbmcgd3Jvbmc/PC9TUEFOPjwvRk9OVD48 bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPVNpbVN1biBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8RElWPg0K ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBzaXplPTI+PFNQQU4gDQog ICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+UmVnYXJzLDwvU1BBTj48L0ZPTlQ+PG86cD48L286 cD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQiPkdlbmd5dTwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9E SVY+PC9CTE9DS1FVT1RFPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000B_01C840E1.AAF8CAF0-- --===============0475236093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0475236093==-- From p2psip-bounces@ietf.org Mon Dec 17 08:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Fxk-00022A-3r; Mon, 17 Dec 2007 08:24:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Fxj-000225-8r for p2psip@ietf.org; Mon, 17 Dec 2007 08:24:51 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Fxi-0006TX-TR for p2psip@ietf.org; Mon, 17 Dec 2007 08:24:51 -0500 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1J4Fxf-0005tv-Us; Mon, 17 Dec 2007 14:24:49 +0100 Received: from wooky.tm.uka.de (i72wooky.tm.uni-karlsruhe.de [141.3.71.49]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id AC28B2FC00C; Mon, 17 Dec 2007 14:24:47 +0100 (CET) Message-ID: <4766789F.5040809@tm.uka.de> Date: Mon, 17 Dec 2007 14:24:47 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: iramx2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Miika Komu wrote: > At least HIPL implements it by using the deployed i3 network in > planetlab. If I recall correctly, HIP packets are transported over i3 > headers through the overlay and ESP packets are sent directly between > the peers. We are currently integrating STUN/ICE with "normal-mode" HIP > and later with Hi3. The implementations are available at: > > http://infrahip.hiit.fi/ > http://www.openhip.org/ > http://www.hip4inter.net/ Which ICE library (PJNATH, Nice,...) do you use in your HIP implementation? Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 09:00:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GWG-0008C3-6B; Mon, 17 Dec 2007 09:00:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GWD-0007yv-Qf for p2psip@ietf.org; Mon, 17 Dec 2007 09:00:30 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4GWB-0003Uv-BU for p2psip@ietf.org; Mon, 17 Dec 2007 09:00:29 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4GVY-0001UE-13; Mon, 17 Dec 2007 08:59:49 -0500 In-Reply-To: <000001c84058$fabe14c0$da07740a@dellwei> References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: From: Philip Matthews Subject: Re: [P2PSIP] Re: HIP pros and cons Date: Mon, 17 Dec 2007 09:00:22 -0500 To: Wei Gengyu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.6 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0383059915==" Errors-To: p2psip-bounces@ietf.org --===============0383059915== Content-Type: multipart/alternative; boundary=Apple-Mail-13-549490038 --Apple-Mail-13-549490038 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed It is true that the definition of "p2p layer" has been vague. This reflects the uncertainty in the WG about how we want to structure our work. When draft-matthews-p2psip-hip-hop-00 was written, it was not yet clear that the WG was going to split SIP from the p2p layer. Hence the use of that term in the draft. However, I think many people these days use "p2p layer" as roughly a synonym for "Peer Protocol". - Philip On 16-Dec-07, at 21:58 , Wei Gengyu wrote: > Henry, > > I am very appreciated your comments. And no new questions about > this thread. > > But I hope to get hints on some already raised questions. > Would you please help me clarify that? > > What is p2p layer? What do you mean "p2p layer"? > > In "draft-matthews-p2psip-hip-hop-00.",we can see 'p2p-layers' > that including IPv4 or IPv6, UDPv4 or UDPv6?, HIP or ESP, TCP or > UDP, and distributed database. > The 'p2p layers'contain five layers. > > I need to know the difference between "p2p layer" and 'p2p layers'. > So, I shall see where you put HIP under p2p layer. > > In "draft-hautakorpi-p2psip-with-hip-01.txt", there are four > suggestions in protocol layer scheme. > Only (a) of Figure 3 contains HIP, but HIP is set on top of Peer > protocol. > whist there is no words of "p2p layer", it seems that Peer protocol > should at that layer. > > Refer to "draft-willis-p2psip-concepts-04 - Concepts and > Terminology for Peer to Peer SIP", > "2. High Level Description > > A P2PSIP Overlay is a collection of nodes organized in a peer-to- > peer > fashion for the purpose of enabling real-time communication > using the > Session Initiation Protocol (SIP). Collectively, the nodes in the > overlay provide a distributed implementation of the location > service > [RFC3261] for mapping Addresses of Record (AoRs) to Contact URIs. > They also provide a transport service by which SIP messages can be > transported between any two nodes in the overlay. > > A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. > The peers in the overlay collectively run a distributed database > algorithm. This distributed database algorithm allows data to be > stored on peers and retrieved in an efficient manner. It may also > ensure that a copy of a data item is stored on more than one > peer, so > that the loss of a peer does not result in the loss of the data > item > to the overlay. " > > Unforunately, there is no explicit definition of "p2p layer" in the > I-D > although so many people say "p2p layer" in this mailing list. > > Even it seems to be a silly quetion, "p2p layer" is still a vague > concept when people say it. > So, I think that WG needs to make this basic definition clear. > > Best regards, > > Gengyu > ----- Original Message ----- > From: Henry Sinnreich > To: Wei Gengyu ; P2PSIP Mailing List > Sent: Monday, December 17, 2007 7:21 AM > Subject: RE: [P2PSIP] Re: HIP pros and cons > > > My problem is when HIP is used at the application layer, > > > or using the same algorithm to generate Peer ID. > > > > HIP runs below the application layer and also below the p2p layer. > > HI is different from the p2p nodeID or application layer (such as > SIP) identifiers, such as AoR. > > > > Henry > > From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > Sent: Sunday, December 16, 2007 5:25 AM > To: P2PSIP Mailing List > Subject: Fw: [P2PSIP] Re: HIP pros and cons > > > > > > ----- Original Message ----- > > From: Wei Gengyu > > To: jeffrey.m.ahrenholz@boeing.com ; spencer@mcsr-labs.org ; Philip > Matthews > > Cc: P2PSIP Mailing List > > Sent: Saturday, December 15, 2007 10:25 AM > > Subject: Re: [P2PSIP] Re: HIP pros and cons > > > > Jeff,Spencer, and Philip, > > > > First, thank you all for your correction. > > > > HIP might work well as RFC4423 defined. > > > > My problem is when HIP is used at the application layer, > > or using the same algorithm to generate Peer ID. > > > > If HIP-like algorithm is used in the overlay while HIP is used > between network layer and transport layer, > > the Peer ID will share the same name space with Host ID. > > For rfc4423, when a node have multiple Host IDs, they only cost > memory spaces a little. > > If one host are permited to have multiple Peer IDs that happen to > belong to one overlay, > > it would incur potential risks to the P2PSIP overlay. > > > > And it seems not be capable to tackle this case in RVS of HIP. > > Is there something wrong? > > > > Regars, > > > > Gengyu > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-13-549490038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 It is true that the definition of "p2p layer" has been vague.
This = reflects the uncertainty in the WG about how we want to structure our = work.

When draft-matthews-p2psip-hip-hop-00 was = written, it was not yet clear that the WG was going to split SIP from = the p2p layer. Hence the use of that term in the draft.

However, I think many = people these days use "p2p layer" as roughly a=C2=A0synonym=C2=A0for = "Peer Protocol".=C2=A0

- Philip

On 16-Dec-07, at = 21:58 , Wei Gengyu wrote:

=
Henry,
=C2=A0
I am very appreciated your comments. = And no new questions about this = thread.
=C2=A0<= /div>
But I hope to = get=C2=A0hints=C2=A0on some already raised questions.
=
Would you please help me clarify = that?
=C2=A0
What is p2p layer? = What do you mean "p2p = layer"?
=C2=A0<= /div>
In = "draft-matthews-p2psip-hip-hop-00.",we can see=C2=A0'p2p-layers' =
that including IPv4 = or IPv6, UDPv4 or UDPv6?, HIP or ESP, TCP or UDP, and distributed = database.
The 'p2p = layers'contain five layers.
=C2=A0
I need to know the difference=C2=A0between = "p2p layer" and 'p2p layers'.
So, I shall=C2=A0see where you put HIP under p2p = layer.
=C2=A0
In = "draft-hautakorpi-p2psip-with-hip-01.txt", there are four suggestions in = protocol layer scheme.
Only (a) of Figure 3 contains HIP, but HIP is set on top of Peer = protocol.
whist=C2=A0t= here is no words of "p2p layer", it seems that Peer protocol should at = that layer.
=C2= =A0
Refer to = =C2=A0"draft-willis-p2psip-concepts-04 - Concepts and Terminology for = Peer to Peer SIP",
"2.= =C2=A0 High Level Description
=C2=A0
=C2=A0=C2=A0 A P2PSIP Overlay is a = collection of nodes organized in a peer-to-peer
=C2=A0=C2=A0 fashion = for the purpose of enabling real-time communication using the
=C2=A0=C2= =A0 Session Initiation Protocol (SIP).=C2=A0 Collectively, the nodes in = the
=C2=A0=C2=A0 overlay provide a distributed implementation of the = location service
=C2=A0=C2=A0 [RFC3261] for mapping Addresses of = Record (AoRs) to Contact URIs.
=C2=A0=C2=A0 They also provide a = transport service by which SIP messages can be
=C2=A0=C2=A0 = transported between any two nodes in the overlay.
=
=C2=A0
=C2=A0=C2=A0 A P2PSIP Overlay consists of = one or more nodes called P2PSIP Peers.
=C2=A0=C2=A0 The peers in the = overlay collectively run a distributed database
=C2=A0=C2=A0 = algorithm.=C2=A0 This distributed database algorithm allows data to = be
=C2=A0=C2=A0 stored on peers and retrieved in an efficient = manner.=C2=A0 It may also
=C2=A0=C2=A0 ensure that a copy of a data = item is stored on more than one peer, so
=C2=A0=C2=A0 that the loss = of a peer does not result in the loss of the data item
=C2=A0=C2=A0 = to the overlay.=C2=A0=C2=A0 "
=C2=A0
Unfor= unately, there is no explicit definition of "p2p layer"=C2=A0in the = I-D
although=C2=A0so=C2= =A0many people say=C2=A0"p2p layer" in this mailing list.
=
=C2=A0
=
Even it seems to be a silly = quetion, "p2p layer" is still a vague concept when people say = it.
So, I think that = WG needs to make=C2=A0this basic definition clear.
=
=C2=A0
Best regards,
=C2=A0
Gengyu=C2=A0
----- Original Message -----
Sent: = Monday, December 17, 2007 7:21 AM
Subject: RE: [P2PSIP] Re: HIP pros and = cons

> My problem is when=C2=A0HIP is used at the = application layer,

> or using the same algorithm to generate = Peer ID.

=C2=A0

HIP runs = below the application layer and also below the p2p layer. =

HI is different from the = p2p nodeID or application layer (such as SIP) identifiers, such as = AoR. =C2=A0

=C2=A0

Henry

From: Wei Gengyu [mailto:weigengyu@vip.sina.com] =
Sent: Sunday, = December 16, 2007 5:25 AM
To: P2PSIP Mailing List
Subject: Fw: [P2PSIP] Re: HIP = pros and cons

=C2=A0

=C2=A0

=

----- Original Message ----- =

From: Wei Gengyu =

Sent: Saturday, December 15, 2007 = 10:25 AM

Subject: Re: [P2PSIP] Re: HIP pros and = cons

=C2=A0

=

Jeff,Spencer, and Philip, =

=C2=A0

First, thank you all for your = correction.

=C2=A0

=

HIP might work=C2=A0well as RFC4423 = defined.

=C2=A0

=

My problem is when=C2=A0HIP is used at the = application layer,

or using the same algorithm to generate Peer = ID.

=C2=A0

=

If HIP-like algorithm=C2=A0is used in the = overlay while=C2=A0HIP is used between network layer and transport = layer,

the Peer ID will share the same name space = with Host ID.

For rfc4423,=C2=A0when a node have multiple = Host IDs, they=C2=A0only cost memory spaces a = little.

If one host are permited to have multiple = Peer IDs that happen to belong to one overlay, =

it=C2=A0would = incur potential risks to the P2PSIP = overlay.

=C2=A0

=

And=C2=A0it seems not be capable to tackle = this case in RVS=C2=A0of HIP.=C2=A0

=

Is there something = wrong?

=C2=A0

=

Regars,

=

=C2=A0

=

Gengyu

P2PSIP mailing list
=

= --Apple-Mail-13-549490038-- --===============0383059915== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0383059915==-- From p2psip-bounces@ietf.org Mon Dec 17 10:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4I3l-0006hC-W4; Mon, 17 Dec 2007 10:39:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4I3k-0006dV-T5 for p2psip@ietf.org; Mon, 17 Dec 2007 10:39:12 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4I3i-000677-QQ for p2psip@ietf.org; Mon, 17 Dec 2007 10:39:12 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J4I33-0002os-Qj; Mon, 17 Dec 2007 16:38:29 +0100 Message-ID: <476697F2.4080903@uni-tuebingen.de> Date: Mon, 17 Dec 2007 16:38:26 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Henry Sinnreich References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> <4765A9FF.7000903@uni-tuebingen.de> <24CCCC428EFEA2469BF046DB3C7A8D223AE414@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE414@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Philip Matthews , p2psip@ietf.org Subject: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry, some of the reasons why applications should not rely on security mechanisms provided by the network/HIP layer, is that there are often a discrepancy between what you want to protect at the application and the protection provided at the network layer, e.g. VPN. For example, if you want to use a HIP overlay for P2PSIP lookup service, and as soon as you find the Callee, you want to perform the subsequent SIP signaling in a B2BUA mode and send your media streams directly using IP routing. (although i know some people will say here you can use HIP. but i think you don't want to use the HIP overlay for routing the media data) In this case, you would use the HIP overlay for the lookup and will need to use SRTP for protecting the media streams. and probably also TLS/DTLS for protecting the B2B SIP signaling. I hope this was clear? Another reason, is that there might a misunderstanding of the security services provided by the HIP layer. e.g. some environments could use HIP for the overlay and think they are safe, while HIP is configured to use null encryption. So, this could lead to security holes quickly in practice. In general, i think it is a good practice if the security of the application does not depend on the security provided by the lower layers (under layer 4). BTW, the 3GPP IMS, for example, uses its own authentication and confidentiality mechanisms independantly of the access network, which is, i think, wise. Also, if you look at things how they work today, you don't want to establish a VPN tunnel to a web server if you want to protect your HTTP traffic. You would rather use TLS. Cheers, Ali Henry Sinnreich wrote: > Ali, > >> In general, security mechanisms on the application layer shoudn't depend >> on security mechanisms in underlaying layers, > > We have no disagreement on the need for strong p2p authentication provided by the enrollment service or server. > > However, do you have any specific reasons to duplicate the VPN-like transmission security of HIP (that would be duplicated in TLS, DTL and SRTP)? What would they be? > > Henry > > > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] > Sent: Sunday, December 16, 2007 4:43 PM > To: Philip Matthews > Cc: Henry Sinnreich; p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > Philip, > > I wouldn't bet on that. ESP can use also null encryption and null data > integrity. (although the combination of both nulls is not allowed) > > In general, security mechanisms on the application layer shoudn't depend > on security mechanisms in underlaying layers, in this case the HIP > overlay layer. > > Cheers, > Ali > > > Philip Matthews wrote: >> Good question! >> >> The most straight-forward way to use HIP for P2PSIP is to protect ALL >> traffic with ESP, thus making TLS, DTLS, and SRTP unnecessary. This >> doesn't mean they cannot be used -- it just means that they are not needed. >> >> - Philip >> >> On 15-Dec-07, at 12:53 , Henry Sinnreich wrote: >> >>> Naïve question: >>> >>> Since HIP ESP data traffic is protected like in a VPN, are TLS, DTLS >>> SRTP still required? I would just like to be sure on this topic. >>> >>> Thanks, Henry >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 11:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ISb-00052K-29; Mon, 17 Dec 2007 11:04:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ISa-00052E-0s for p2psip@ietf.org; Mon, 17 Dec 2007 11:04:52 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ISY-0006kC-AE for p2psip@ietf.org; Mon, 17 Dec 2007 11:04:52 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7462A2F7C; Mon, 17 Dec 2007 18:04:49 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 92D262E20; Mon, 17 Dec 2007 18:04:42 +0200 (EET) Date: Mon, 17 Dec 2007 18:04:42 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20071214145748.E37DF33C6D@delta.rtfm.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Fri, 14 Dec 2007, Eric Rescorla wrote: > At Fri, 14 Dec 2007 09:08:30 +0200 (EET), > Miika Komu wrote: >> >> On Thu, 13 Dec 2007, Eric Rescorla wrote: >> >>> At Thu, 13 Dec 2007 22:51:41 +0200 (EET), >>> Miika Komu wrote: >>>> >>>> On Thu, 13 Dec 2007, Eric Rescorla wrote: >>>> >>>> Hi Eric, >>>> >>>>>> * Why can't we just use a centralized enrollment server to distribute >>>>>> mandatory certificates for Host Identities? The enrollment server could >>>>>> still throttle based on the IP address of the client, which I assume you >>>>>> we suggesting? >>>>> >>>>> I don't know what this means. The entire point of the HIP public-key->HIT >>>>> relationship was to make HITs self-authenticating. Once you're using >>>>> certificates, you've dramatically changed the situation. >>>> >>>> It means that the centralized enrollment server has to sign your public >>>> key, possibly along with some other data such as URI. When too many >>>> enrollments are coming from a single IP, the enrollment server just drops >>>> the enrollments. Without successful enrollment, you cannot be part of the >>>> overlay. >>>> >>>> The enrollment procedure could be folded nicely to a HIP base exchange >>>> with some registration parameters: >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-hip-registration-02.txt >>>> >>>> It is possible to do this, of course, at the upper layers. >>> >>> Yes, but I don't see how HIP is offering any advantage here. >> >> Ok, let's forget about the certificates with HIP then. If the clients >> create their own public keys and the centralized enrollment server >> requires the client to provide a credit card number or captcha, I don't >> see what is the problem then? > > Then how does a relying party verify that the client actually enrolled > rather than just generated their own key and didn't enroll? The same way as without public keys. I fail to see the problem here. >> I don't really see why the enrollment server >> needs to create the identifiers in such a case. The cost of an attack is >> just too expensive. > > Huh? Attacking a single point on the overlay is the cost of doing > a single captcha (about $.01). Let's then rely on the credit card payment as you suggested. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 11:17:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4If3-0003u7-To; Mon, 17 Dec 2007 11:17:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4If3-0003qm-2Y for p2psip@ietf.org; Mon, 17 Dec 2007 11:17:45 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4If2-0004E1-M7 for p2psip@ietf.org; Mon, 17 Dec 2007 11:17:44 -0500 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J4If1-0002pr-VB for p2psip@ietf.org; Mon, 17 Dec 2007 17:17:43 +0100 Message-ID: <4766A124.4080906@uni-tuebingen.de> Date: Mon, 17 Dec 2007 17:17:40 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: P2PSIP Mailing List References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [P2PSIP] HIP performance concerns (was HIP pros and cons) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, some questions for the HIP experts among us: - HIP uses a Base Exchange (BEX) with 4 messages, and the BEX contains a diffie hellman key exchange. (as you know, diffie hellman might cause some performance problems on small devices) Do i need a HIP BEX each time before I can exchange any message with another peer in the overlay? for example P2P routing messages? as you know, P2P networks have generally the property that you need to exchange messages frequently with other peers, for routing purposes, for DHT maintenane, etc. So, it wouldn't be very efficient if i need to perform a HIP BEX each time before I can exchange any other message, in particular under high churn conditions. - if you do mobility with HIP, you will need to update the IPSec SAs in the kernel when a handover occurs. Is that correct? How well does this work? Has there been some experiments that show that HIP can provide seamless mobility? If yes, please provide a reference. Cheers, Ali -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 11:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JAW-0005yc-GT; Mon, 17 Dec 2007 11:50:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JAV-0005yW-In for p2psip@ietf.org; Mon, 17 Dec 2007 11:50:15 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4JAV-000596-9Q for p2psip@ietf.org; Mon, 17 Dec 2007 11:50:15 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 38F0433C53; Mon, 17 Dec 2007 08:44:38 -0800 (PST) Date: Mon, 17 Dec 2007 08:44:36 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071217164438.38F0433C53@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 17 Dec 2007 18:04:42 +0200 (EET), Miika Komu wrote: > The same way as without public keys. I fail to see the problem here. I don't even understand what you're proposing any more. If you want to describe a specific proposal, I'll be happy to address its merits. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 14:31:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Lgt-0001Q1-2S; Mon, 17 Dec 2007 14:31:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Lgr-0001Oy-Fh for p2psip@ietf.org; Mon, 17 Dec 2007 14:31:49 -0500 Received: from quinthar.com ([72.52.120.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4Lgr-0004pA-0b for p2psip@ietf.org; Mon, 17 Dec 2007 14:31:49 -0500 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 17 Dec 2007 11:31:44 -0800 From: "David Barrett" To: "'Ali Fessi'" , "'Henry Sinnreich'" Subject: RE: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) Date: Mon, 17 Dec 2007 11:31:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <476697F2.4080903@uni-tuebingen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchAwvuoY/Gyq8f3Qz24hGnz/zCe6QAGLf1w X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Philip Matthews' , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] > Subject: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) > > Also, if you look at things how they work today, you don't want to > establish a VPN tunnel to a web server if you want to protect your HTTP > traffic. You would rather use TLS. I think the point is if you already have a VPN connection established with the webserver, then you don't need to *also* use TLS. Similarly, if you already had NAT-traversal built in, then you wouldn't *also* use ICE. If I understand correctly (Philip -- Please correct me if I'm wrong), HIP effectively gives us a NAT-traversing VPN connection "out of the box" for every TCP connection established, rendering much of TLS redundant. (Clearly there are still the authentication and authorization benefits, but those could be layered atop HIP for those streams that need it.) Personally, I think the idea of a P2P layer that provides standard NAT-traversal and encryption is fantastic. Ideally it'd be implemented with an open-source library having an interface almost exactly like the Berkeley Socket API, and then we can re-establish the end-to-end principle of the net -- with "free" encryption out of the box. (Free in terms of coding time, not CPU.) If such a thing existed, it seems a no-brainer to use it for P2P-SIP, and pretty much everything else online. -david PS: Philip -- Does HIP only provide a TCP-like reliable peer connection, or would it also provide a UDP-like lossy peer connection? _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 17:22:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OLs-0005BN-Do; Mon, 17 Dec 2007 17:22:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OLr-000594-G0 for p2psip@ietf.org; Mon, 17 Dec 2007 17:22:19 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4OLo-0003YN-Tl for p2psip@ietf.org; Mon, 17 Dec 2007 17:22:19 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT700KQAST3QL@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 17 Dec 2007 14:22:16 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JT700ECSSSXEA@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 17 Dec 2007 14:22:15 -0800 (PST) Date: Mon, 17 Dec 2007 16:21:51 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Re: HIP pros and cons To: Philip Matthews , Wei Gengyu Message-id: <024401c840fb$39097830$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> X-Spam-Score: 0.6 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1678923836==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1678923836== Content-type: multipart/alternative; boundary="Boundary_(ID_P/kazLXnk+MDjRo+TWA6xg)" This is a multi-part message in MIME format. --Boundary_(ID_P/kazLXnk+MDjRo+TWA6xg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Just confirming that Philip's understanding matches mine - we have = descriptive text dating from the days where several proposals were for = new SIP methods, new SIP headers, or some combination of the two, and = not as much descriptive text that was written after we (appear to have) = agreed that SIP would not be the peer protocol. It seems to me there are things that we knew when the peer protocol was = based on SIP - for a trivial example, what level of a protocol stack is = responsible for retransmission? SIP had its own timers to support UDP = operation, so naturally we would use those - and we haven't thought = through (on-list) what the corresponding retransmission characteristics = of a non-SIP peer protocol should be. There are other, similar questions ("do we need a hop count in the peer = protocol?"). Maybe everyone on this list except me knows the answers, = but they aren't written down as working group consensus.=20 I can understand why Gengyu is confused, because I am, too. Thanks, Spencer p.s. I am reminded of the Tony Hoare quote, "I don't know what the = programming language of the year 2000 will look like, but I know it will = be called Fortran". I hope we don't get to the point where we don't know = what the peer protocol will look like, but we know it will be called "X" = (for "X", substitute your favorite candidate proposal). ----- Original Message -----=20 From: Philip Matthews=20 To: Wei Gengyu=20 Cc: Henry Sinnreich ; P2PSIP Mailing List=20 Sent: Monday, December 17, 2007 8:00 AM Subject: Re: [P2PSIP] Re: HIP pros and cons It is true that the definition of "p2p layer" has been vague. This reflects the uncertainty in the WG about how we want to structure = our work. When draft-matthews-p2psip-hip-hop-00 was written, it was not yet = clear that the WG was going to split SIP from the p2p layer. Hence the = use of that term in the draft. However, I think many people these days use "p2p layer" as roughly = a=C2 synonym=C2 for "Peer Protocol".=C2=20 - Philip On 16-Dec-07, at 21:58 , Wei Gengyu wrote: Henry, =C2 =20 I am very appreciated your comments. And no new questions about this = thread. =C2=20 But I hope to get=C2 hints=C2 on some already raised questions.=20 Would you please help me clarify that? =C2=20 What is p2p layer? What do you mean "p2p layer"? =C2=20 In "draft-matthews-p2psip-hip-hop-00.",we can see=C2 'p2p-layers'=20 that including IPv4 or IPv6, UDPv4 or UDPv6?, HIP or ESP, TCP or = UDP, and distributed database.=20 The 'p2p layers'contain five layers.=20 =C2=20 I need to know the difference=C2 between "p2p layer" and 'p2p = layers'. So, I shall=C2 see where you put HIP under p2p layer. =C2=20 In "draft-hautakorpi-p2psip-with-hip-01.txt", there are four = suggestions in protocol layer scheme. Only (a) of Figure 3 contains HIP, but HIP is set on top of Peer = protocol. whist=C2 there is no words of "p2p layer", it seems that Peer = protocol should at that layer. =C2=20 Refer to =C2 "draft-willis-p2psip-concepts-04 - Concepts and = Terminology for Peer to Peer SIP", "2.=C2 High Level Description =C2=20 =C2 =C2 A P2PSIP Overlay is a collection of nodes organized in a = peer-to-peer =C2 =C2 fashion for the purpose of enabling real-time communication = using the =C2 =C2 Session Initiation Protocol (SIP).=C2 Collectively, the = nodes in the =C2 =C2 overlay provide a distributed implementation of the = location service =C2 =C2 [RFC3261] for mapping Addresses of Record (AoRs) to Contact = URIs. =C2 =C2 They also provide a transport service by which SIP messages = can be =C2 =C2 transported between any two nodes in the overlay. =C2=20 =C2 =C2 A P2PSIP Overlay consists of one or more nodes called = P2PSIP Peers. =C2 =C2 The peers in the overlay collectively run a distributed = database =C2 =C2 algorithm.=C2 This distributed database algorithm allows = data to be =C2 =C2 stored on peers and retrieved in an efficient manner.=C2 = It may also =C2 =C2 ensure that a copy of a data item is stored on more than = one peer, so =C2 =C2 that the loss of a peer does not result in the loss of the = data item =C2 =C2 to the overlay.=C2 =C2 " =C2=20 Unforunately, there is no explicit definition of "p2p layer"=C2 in = the I-D although=C2 so=C2 many people say=C2 "p2p layer" in this mailing = list. =C2=20 Even it seems to be a silly quetion, "p2p layer" is still a vague = concept when people say it. So, I think that WG needs to make=C2 this basic definition clear.=20 =C2=20 Best regards, =C2=20 Gengyu=C2=20 ----- Original Message -----=20 From: Henry Sinnreich=20 To: Wei Gengyu ; P2PSIP Mailing List=20 Sent: Monday, December 17, 2007 7:21 AM Subject: RE: [P2PSIP] Re: HIP pros and cons > My problem is when=C2 HIP is used at the application layer,=20 > or using the same algorithm to generate Peer ID.=20 =C2=20 HIP runs below the application layer and also below the p2p layer. = HI is different from the p2p nodeID or application layer (such as = SIP) identifiers, such as AoR. =C2=20 =C2=20 Henry -------------------------------------------------------------------------= - From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: Sunday, December 16, 2007 5:25 AM To: P2PSIP Mailing List Subject: Fw: [P2PSIP] Re: HIP pros and cons =C2=20 =C2=20 ----- Original Message -----=20 From: Wei Gengyu=20 To: jeffrey.m.ahrenholz@boeing.com ; spencer@mcsr-labs.org ; = Philip Matthews=20 Cc: P2PSIP Mailing List=20 Sent: Saturday, December 15, 2007 10:25 AM Subject: Re: [P2PSIP] Re: HIP pros and cons =C2=20 Jeff,Spencer, and Philip,=20 =C2=20 First, thank you all for your correction. =C2=20 HIP might work=C2 well as RFC4423 defined. =C2=20 My problem is when=C2 HIP is used at the application layer,=20 or using the same algorithm to generate Peer ID.=20 =C2=20 If HIP-like algorithm=C2 is used in the overlay while=C2 HIP is = used between network layer and transport layer, the Peer ID will share the same name space with Host ID. For rfc4423,=C2 when a node have multiple Host IDs, they=C2 only = cost memory spaces a little. If one host are permited to have multiple Peer IDs that happen to = belong to one overlay,=20 it=C2 would incur potential risks to the P2PSIP overlay. =C2=20 And=C2 it seems not be capable to tackle this case in RVS=C2 of = HIP.=C2=20 Is there something wrong? =C2=20 Regars, =C2=20 Gengyu _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip -------------------------------------------------------------------------= ----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_P/kazLXnk+MDjRo+TWA6xg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Just confirming that Philip's = understanding matches=20 mine - we have descriptive text dating from the days where several = proposals=20 were for new SIP methods, new SIP headers, or some combination of the = two, and=20 not as much descriptive text that was written after we (appear to have) = agreed=20 that SIP would not be the peer protocol.
 
It seems to me there are things that we = knew when=20 the peer protocol was based on SIP - for a trivial example, what level = of a=20 protocol stack is responsible for retransmission? SIP had its own timers = to=20 support UDP operation, so naturally we would use those - and we haven't = thought=20 through (on-list) what the corresponding retransmission characteristics = of a=20 non-SIP peer protocol should be.
 
There are other, similar questions ("do = we need a=20 hop count in the peer protocol?"). Maybe everyone=20 on this list except me knows the answers, but they aren't written down = as=20 working group consensus. 
 
I can understand why Gengyu is = confused, because I=20 am, too.
 
Thanks,
 
Spencer
 
p.s. I am reminded of the Tony Hoare = quote, "I don't know what the programming language of = the year 2000=20 will look like, but I know it will be called Fortran". I hope we don't = get to=20 the point where we don't know what the peer protocol will look like, but = we know=20 it will be called "X" (for "X", substitute your favorite candidate=20 proposal).
----- Original Message -----
From:=20 Philip Matthews
Cc: Henry Sinnreich ; P2PSIP Mailing = List=20
Sent: Monday, December 17, 2007 = 8:00=20 AM
Subject: Re: [P2PSIP] Re: HIP = pros and=20 cons

It is true that the definition of "p2p layer" has been = vague.
This reflects the uncertainty in the WG about how we want to = structure=20 our work.

When draft-matthews-p2psip-hip-hop-00 was written, it was not yet = clear=20 that the WG was going to split SIP from the p2p layer. Hence the use = of that=20 term in the draft.

However, I think many people these days use "p2p layer" as = roughly=20 a=C2 synonym=C2 for "Peer Protocol".=C2 

- Philip

On 16-Dec-07, at 21:58 , Wei Gengyu wrote:
Henry,
=C2 
I am very appreciated your = comments. And no new questions about this = thread.
=C2 
But I hope to = get=C2 hints=C2 on some already=20 raised questions.
Would you please help me = clarify that?
=C2 
What is p2p layer? What do=20 you mean "p2p layer"?
=C2 
In = "draft-matthews-p2psip-hip-hop-00.",we can=20 see=C2 'p2p-layers'
that including IPv4 or IPv6, = UDPv4 or UDPv6?, HIP or=20 ESP, TCP or UDP, and distributed database.
The 'p2p layers'contain five = layers.
=C2 
I need to know the = difference=C2 between "p2p=20 layer" and 'p2p layers'.
So, I shall=C2 see where = you put HIP under p2p=20 layer.
=C2 
In = "draft-hautakorpi-p2psip-with-hip-01.txt", there=20 are four suggestions in protocol layer scheme.
Only (a) of Figure 3 contains = HIP, but HIP is set on=20 top of Peer protocol.
whist=C2 there is no words = of "p2p layer", it=20 seems that Peer protocol should at that layer.
=C2 
Refer to = =C2 "draft-willis-p2psip-concepts-04 -=20 Concepts and Terminology for Peer to Peer SIP",
"2.=C2  High Level = Description
=C2 
=C2 =C2  A P2PSIP = Overlay is a collection of=20 nodes organized in a peer-to-peer
=C2 =C2  fashion for = the purpose=20 of enabling real-time communication using the
=C2 =C2  = Session=20 Initiation Protocol (SIP).=C2  Collectively, the nodes in=20 the
=C2 =C2  overlay provide a distributed = implementation of the=20 location service
=C2 =C2  [RFC3261] for mapping = Addresses of Record=20 (AoRs) to Contact URIs.
=C2 =C2  They also provide a = transport=20 service by which SIP messages can be
=C2 =C2  = transported between=20 any two nodes in the overlay.
=C2 
=C2 =C2  A P2PSIP = Overlay consists of one or=20 more nodes called P2PSIP Peers.
=C2 =C2  The peers in = the overlay=20 collectively run a distributed database
=C2 =C2  = algorithm.=C2 =20 This distributed database algorithm allows data to = be
=C2 =C2 =20 stored on peers and retrieved in an efficient manner.=C2  It = may=20 also
=C2 =C2  ensure that a copy of a data item is = stored on more=20 than one peer, so
=C2 =C2  that the loss of a peer does = not result=20 in the loss of the data item
=C2 =C2  to the = overlay.=C2 =C2 =20 "
=C2 
Unforunately, there is no=20 explicit definition of "p2p layer"=C2 in the I-D
although=C2 so=C2 many people = say=C2 "p2p=20 layer" in this mailing list.
=C2 
Even it seems to be a silly = quetion, "p2p layer" is=20 still a vague concept when people say it.
So, I think that WG needs to = make=C2 this basic=20 definition clear.
=C2 
Best regards,
=C2 
Gengyu=C2 
----- Original Message = -----
From:=20 Henry=20 Sinnreich
To: Wei Gengyu ; P2PSIP = Mailing=20 List
Sent: Monday, = December 17, 2007 7:21=20 AM
Subject: RE: = [P2PSIP] Re: HIP pros=20 and cons

> My problem is = when=C2 HIP is used=20 at the application layer,

> or using the same algorithm to = generate Peer=20 ID.

=C2 

HIP runs below the application layer and = also=20 below the p2p layer.

HI is different from the p2p nodeID or = application=20 layer (such as SIP) identifiers, such as AoR.=20 =C2 

=C2 

Henry

From: Wei=20 Gengyu [mailto:weigengyu@vip.sina.com]= =20
Sent: Sunday, = December=20 16, 2007 5:25 AM
To:=20 P2PSIP Mailing List
Subject: Fw: [P2PSIP] Re: = HIP pros=20 and cons

=C2 

=C2 

----- Original Message -----=20

From: Wei Gengyu=20

To: jeffrey.m.ahrenholz@boeing= .com=20 ; spencer@mcsr-labs.org ; = Philip Matthews=20

Sent: Saturday, December 15, = 2007 10:25=20 AM

Subject: Re: [P2PSIP] Re: HIP pros = and=20 cons

=C2 

Jeff,Spencer, and Philip,=20

=C2 

First, thank you all for your=20 correction.

=C2 

HIP might work=C2 well as RFC4423=20 defined.

=C2 

My problem is when=C2 HIP is used = at the=20 application layer,

or using the same algorithm to generate = Peer ID.=20

=C2 

If HIP-like algorithm=C2 is used in = the overlay=20 while=C2 HIP is used between network layer and transport=20 layer,

the Peer ID will share the same name = space with=20 Host ID.

For rfc4423,=C2 when a node have = multiple Host=20 IDs, they=C2 only cost memory spaces a=20 little.

If one host are permited to have = multiple Peer IDs=20 that happen to belong to one overlay, =

it=C2 would incur potential risks = to the P2PSIP=20 overlay.

=C2 

And=C2 it seems not be capable to = tackle this=20 case in RVS=C2 of = HIP.=C2 

Is there something=20 wrong?

=C2 

Regars,

=C2 

Gengyu

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP = mailing=20 = list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip<= BR> --Boundary_(ID_P/kazLXnk+MDjRo+TWA6xg)-- --===============1678923836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1678923836==-- From p2psip-bounces@ietf.org Mon Dec 17 17:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OTo-0003ch-Er; Mon, 17 Dec 2007 17:30:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OTm-0003RD-77 for p2psip@ietf.org; Mon, 17 Dec 2007 17:30:30 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4OTl-0003ik-Fk for p2psip@ietf.org; Mon, 17 Dec 2007 17:30:30 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4OTk-0002TN-35; Mon, 17 Dec 2007 17:30:29 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <476697F2.4080903@uni-tuebingen.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) Date: Mon, 17 Dec 2007 17:30:24 -0500 To: David Barrett , Ali Fessi X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Let me try to answer both Ali and David's e-mails by giving a brief description of what happens. I will give a generic description that works for all three HIP-based proposals. Applications running in the overlay uses special IP addresses to identify other peers in the overlay. These addresses are drawn from a special range of addresses so they can be distinguished from regular addresses. So say an application running on peer X issues a TCP connect() to a port on peer Y, using the special IP address for peer Y. This connect() call causes the TCP stack on X to send a SYN packet. In the Windows implementation, this SYN packet in intercepted at the link layer by a TAP device driver and diverted to a user-space process. At this point, the user-space process checks if there is an existing direct connection to peer Y. Assuming one is, and assuming that ESP is used (*), the IP header is removed, and three new headers (ESP over UDP over IP) are added to the packet. The addresses and ports in the new UDP and IP packets are "real" addresses and ports determined using ICE, not the virtual addresses used in the removed IP header. Thus the packet looks like: IP | UDP | ESP | TCP (SYN) I like to think of it as a ESP over UDP "pipe" between X and Y, over which all application packets are multiplexed. If no existing direct connection exists between X and Y, then one is established using signaling (**) that goes hop-by-hop around the overlay, or via a signaling relay. (*) The WITH-HIP proposal always uses ESP; the HIP-HOP proposal uses ESP by default, but provides a way to not use it; and the ID-LOC proposal currently does not use it, though that may change in the next revision. (**) The details on how signaling is done depends on the proposal. Ali wrote: > For example, if you want to use a HIP overlay for P2PSIP lookup > service, and as soon as you find the Callee, you want to perform > the subsequent SIP signaling in a B2BUA mode and send your media > streams directly using IP routing. (although i know some people > will say here you can use HIP. but i think you don't want to use > the HIP overlay for routing the media data) > > In this case, you would use the HIP overlay for the lookup and will > need to use SRTP for protecting the media streams. and probably > also TLS/DTLS for protecting the B2B SIP signaling. In all three proposals, media packets would flow directly between the X and Y, and not hop-by-hop around the overlay. So when ESP was used, there would be no need to use STRP for media, or TLS or DTLS for signaling. > Another reason, is that there might a misunderstanding of the > security services provided by the HIP layer. e.g. some environments > could use HIP for the overlay and think they are safe, while HIP is > configured to use null encryption. So, this could lead to security > holes quickly in practice. I think the risk of this happening depends on how we write the standard. I don't think the risk here is any greater than never using ESP and applications not using (D)TLS when they should. David Barrett wrote: > I think the point is if you already have a VPN connection > established with > the webserver, then you don't need to *also* use TLS. Similarly, > if you > already had NAT-traversal built in, then you wouldn't *also* use ICE. > > If I understand correctly (Philip -- Please correct me if I'm > wrong), HIP > effectively gives us a NAT-traversing VPN connection "out of the > box" for > every TCP connection established, rendering much of TLS redundant. > (Clearly > there are still the authentication and authorization benefits, but > those > could be layered atop HIP for those streams that need it.) Let me just note that the current HIP specification is not defined to work in an overlay. The various proposals (HIP-HOP, WITH-HIP, ID-LOC) describe how to extend it to work in an overlay. But briefly, yes. > > Personally, I think the idea of a P2P layer that provides standard > NAT-traversal and encryption is fantastic. Ideally it'd be > implemented with > an open-source library having an interface almost exactly like the > Berkeley > Socket API, and then we can re-establish the end-to-end principle > of the net > -- with "free" encryption out of the box. (Free in terms of coding > time, > not CPU.) Though library implementations are possible, my preference is for a VPN-like implementation where applications continue to use the kernel's Berkeley Socket API, and packets are intercepted at the link layer. This is the way VPNs are implemented today (at least on Windows -- other implementation techniques are available on Unix platforms). > > If such a thing existed, it seems a no-brainer to use it for P2P- > SIP, and > pretty much everything else online. There are three open-source HIP implementations available today, which between them support virtually all major platforms. However, NAT traversal support is still work-in-progress, and the details of working in an overlay is the part that we discussing. > -david > > PS: Philip -- Does HIP only provide a TCP-like reliable peer > connection, or > would it also provide a UDP-like lossy peer connection? The short answer is: Yes. The longer answer is that all three proposals support, at a minimum, a "UDP pipe" between peer X and peer Y over which TCP connection and UDP packets can be multiplexed. This can be shown in a drawing as follows -----------Outer UDP Pipe ---------------- <===== TCP Connection #1 =============> X <===== TCP Connection #2 =============> Y <===== UDP packet stream #1 ==========> <===== UDP packet stream #2 ==========> ------------------------------------------ In WITH-HIP and in HIP-HOP, this UDP pipe always uses ESP. In ID-LOC, this pipe does not currently use ESP (due to concerns about double encryption) but probably will in the next version. HIP-HOP and ID-LOC currently support other encapsulations as well. See the ID-LOC draft for a description. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 17 19:46:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qbm-0002bd-0L; Mon, 17 Dec 2007 19:46:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qbk-0002b3-K7 for p2psip@ietf.org; Mon, 17 Dec 2007 19:46:52 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Qbj-0005r9-6v for p2psip@ietf.org; Mon, 17 Dec 2007 19:46:52 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4Qbi-0001py-2w; Mon, 17 Dec 2007 19:46:51 -0500 In-Reply-To: <4766A124.4080906@uni-tuebingen.de> References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> <4766A124.4080906@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6191EB54-4A0F-4D97-9F26-CEEE88CBB2B7@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] HIP performance concerns (was HIP pros and cons) Date: Mon, 17 Dec 2007 19:27:54 -0500 To: Ali Fessi X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Before answering your question, I think it is important to point out the following: * There is HIP as specified in documents just approved by the IESG. This version of HIP does not work in an overlay and does not include NAT Traversal. I will call this "basic HIP" * There is HIP with NAT Traversal, which is an official work item of the HIP WG, but is not yet finished. * Then there are three proposals in P2PSIP: - HIP-HOP: Proposes to extend HIP to allow it to set up connections in the overlay - WITH-HIP: Proposes to use run HIP over the Peer Protocol to set up connections in the overlay - ID-LOC: Proposes to take ideas from HIP and include them in the Peer Protocol All three drafts are just individual submissions. Also note that there are two HIP groups: a HIP working group and a HIP research group. The Working Group is looking at the NAT Traversal issues. The Research Group is the one looking at applications of HIP. On 17-Dec-07, at 11:17 , Ali Fessi wrote: > Hi all, > > some questions for the HIP experts among us: > > - HIP uses a Base Exchange (BEX) with 4 messages, and the BEX > contains a diffie hellman key exchange. (as you know, diffie > hellman might cause some performance problems on small devices) Yes. I believe that tests with a Nokia Tablet (a small mobile device) have shown that the Diffie-Hellman is not a problem in practice. For details, ask on the HIP RG list (see below). > > Do i need a HIP BEX each time before I can exchange any message > with another peer in the overlay? for example P2P routing messages? No. All three proposals mentioned above propose to use the scheme first described in draft-matthews-p2psip-nats-and-overlays whereby there are permanent connections to various other peers in the overlay. RELOAD now also uses this scheme. > > as you know, P2P networks have generally the property that you need > to exchange messages frequently with other peers, for routing > purposes, for DHT maintenane, etc. So, it wouldn't be very > efficient if i need to perform a HIP BEX each time before I can > exchange any other message, in particular under high churn conditions. Luckily, this is not required. See previous answer. > > - if you do mobility with HIP, you will need to update the IPSec > SAs in the kernel when a handover occurs. Is that correct? How well > does this work? Has there been some experiments that show that HIP > can provide seamless mobility? If yes, please provide a reference. For "basic HIP", I understand the answer is no. For other forms of HIP, I believe the answer will be the same. However, I will say that I am not a security expert, nor am I an expert on HIP. For more details on HIP mobility, I suggest you ask your question on the HIP RG mailing list: hipsec-rg@listserv.cybertrust.com - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 00:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4V7U-0003Tq-Kf; Tue, 18 Dec 2007 00:35:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4V7S-0003Sf-Ur for p2psip@ietf.org; Tue, 18 Dec 2007 00:35:55 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4V7S-0004Lh-I1 for p2psip@ietf.org; Tue, 18 Dec 2007 00:35:54 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBI5ZmMb022442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Dec 2007 21:35:49 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBI5ZlGu016752; Mon, 17 Dec 2007 21:35:48 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBI5Zlim016749; Mon, 17 Dec 2007 21:35:47 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 21:35:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP performance concerns (was HIP pros and cons) Date: Mon, 17 Dec 2007 21:35:46 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049A95@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <6191EB54-4A0F-4D97-9F26-CEEE88CBB2B7@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP performance concerns (was HIP pros and cons) Thread-Index: AchBD4R0DbkkGLjnTa2Y7+566lwHHgAJfVOQ References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei><4766A124.4080906@uni-tuebingen.de> <6191EB54-4A0F-4D97-9F26-CEEE88CBB2B7@magma.ca> From: "Henderson, Thomas R" To: "Philip Matthews" , "Ali Fessi" X-OriginalArrivalTime: 18 Dec 2007 05:35:47.0413 (UTC) FILETIME=[D7798050:01C84137] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > > > > - if you do mobility with HIP, you will need to update the IPSec =20 > > SAs in the kernel when a handover occurs. Is that correct?=20 > How well =20 > > does this work? Has there been some experiments that show that HIP =20 > > can provide seamless mobility? If yes, please provide a reference. >=20 > For "basic HIP", I understand the answer is no. > For other forms of HIP, I believe the answer will be the same. > However, I will say that I am not a security expert, nor am I an =20 > expert on HIP. For basic HIP, the answer is yes; the SAs are updated whenever the locator changes so that the outer header is correct. The SAs may often be rekeyed at the same time. We have been doing so-called vertical handoffs (across access technologies) at Boeing using HIP, including voice handoffs. I would not call it seamless, though; it is a layer-3 end-to-end handoff. The handoff latency has several components, including round-trip time, time to detect a path change event, and signature operations. I don't have any recent results to cite, but we published some results from an early HIP implementation at the 2003 IEEE WCNC conference [*], where we found that HIP readdressing events on Pentium II 266 MHz machines with software encryption took less than a second to complete. =20 Tom [*] Henderson, T.R., J.M. Ahrenholz, and J.H. Kim, " Experience with the Host Identity Protocol for Secure Host Mobility and Multihoming," IEEE Wireless Communications and Networking Conference (WCNC), New Orleans, March 2003.=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 03:53:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4YCv-0007DG-Ux; Tue, 18 Dec 2007 03:53:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4YCu-0007Cp-BJ for p2psip@ietf.org; Tue, 18 Dec 2007 03:53:44 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4YCu-00024q-0t for p2psip@ietf.org; Tue, 18 Dec 2007 03:53:44 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 4047C33C69; Tue, 18 Dec 2007 00:48:07 -0800 (PST) Date: Tue, 18 Dec 2007 00:48:06 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071218084807.4047C33C69@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 17 Dec 2007 17:30:24 -0500, Philip Matthews wrote: > In all three proposals, media packets would flow directly between the > X and Y, and not hop-by-hop around the overlay. So when ESP was used, > there would be no need to use STRP for media, or TLS or DTLS for > signaling. This is arguably a bug, not a feature. SRTP was explicitly designed to have very low overhead: just the bits of the authentication tag itself, with no header, etc. The rationale for this design was that RTP packets tend to be very small and so the overhead for the header, IV, etc. was significant. In cases where that type of constraint applies, then wrapping the RTP in ESP would be bad. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 04:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Z24-0007ee-0v; Tue, 18 Dec 2007 04:46:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Z22-0007cm-Mo for p2psip@ietf.org; Tue, 18 Dec 2007 04:46:34 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4Z21-0000qO-0c for p2psip@ietf.org; Tue, 18 Dec 2007 04:46:34 -0500 Received: (qmail invoked by alias); 18 Dec 2007 09:46:31 -0000 Received: from p549843FC.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.67.252] by mail.gmx.net (mp044) with SMTP; 18 Dec 2007 10:46:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+63EESgki6bDHv0w3xNCFPfU0QcuvXORdTtats24 fnMGaN0A3kSIC9 Message-ID: <476796F5.1040207@gmx.net> Date: Tue, 18 Dec 2007 10:46:29 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> In-Reply-To: <20071218084807.4047C33C69@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This was one of the concern raised when we looked in using HIP together with SIP a few years ago. As a consequence we wrote a separate document to allow HIP to create SRTP security associations. A student also implemented it. The interaction between the different layers wasn't easy. Ciao Hannes Eric Rescorla wrote: > At Mon, 17 Dec 2007 17:30:24 -0500, > Philip Matthews wrote: > >> In all three proposals, media packets would flow directly between the >> X and Y, and not hop-by-hop around the overlay. So when ESP was used, >> there would be no need to use STRP for media, or TLS or DTLS for >> signaling. >> > > This is arguably a bug, not a feature. > > SRTP was explicitly designed to have very low overhead: just the > bits of the authentication tag itself, with no header, etc. The > rationale for this design was that RTP packets tend to be very > small and so the overhead for the header, IV, etc. was significant. > In cases where that type of constraint applies, then wrapping the > RTP in ESP would be bad. > > -Ekr > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 10:20:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eEq-00035V-Jw; Tue, 18 Dec 2007 10:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eEq-00035Q-2x for p2psip@ietf.org; Tue, 18 Dec 2007 10:20:08 -0500 Received: from mail6.primus.ca ([216.254.141.173] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4eEn-00019X-To for p2psip@ietf.org; Tue, 18 Dec 2007 10:20:08 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1J4eEd-0001or-2M; Tue, 18 Dec 2007 10:19:55 -0500 In-Reply-To: <20071218084807.4047C33C69@delta.rtfm.com> References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95F0751F-A73C-4CC6-9BC4-A4AEB8A3A54A@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) Date: Tue, 18 Dec 2007 10:19:50 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 18-Dec-07, at 03:48 , Eric Rescorla wrote: > At Mon, 17 Dec 2007 17:30:24 -0500, > Philip Matthews wrote: >> In all three proposals, media packets would flow directly between the >> X and Y, and not hop-by-hop around the overlay. So when ESP was used, >> there would be no need to use STRP for media, or TLS or DTLS for >> signaling. > > This is arguably a bug, not a feature. > > SRTP was explicitly designed to have very low overhead: just the > bits of the authentication tag itself, with no header, etc. The > rationale for this design was that RTP packets tend to be very > small and so the overhead for the header, IV, etc. was significant. > In cases where that type of constraint applies, then wrapping the > RTP in ESP would be bad. Glad you brought that up. I have been debating that point for some months now. Both HIP-HOP and ID-LOC provide for an alternative encapsulation (the "null-encapsulation" as it is called in ID-LOC). This encapsulation does not add any additional headers, but just modified the addresses and ports in the existing IP and transport headers. Cullen has described this as making the node act like a NAT. The two encapsulations are: IP | UDP | ESP | transport | app (called the "Outer-DUP" encapsulation in ID-LOC (*) ) and IP | transport | app (null-encapsulation) The benefits of the null-encapsulation are: * It does not add any additional overhead The benefits of the "Outer-UDP" encapsulation are: * It is easy to encrypt all packets * Transport protocols such as SCTP, DCCP, and UDP-lite can be easily transported through NATs * There is just one "UDP pipe" between the source and destination over which all flows are multiplexed, and thus you need just one ICE exchange (rather than one per flow as with the null-encapsulation). I have been debating the pros and cons of the two encapsulations. Should P2PSIP support both encapsulations? Or should we just pick one? VPNs seem to do fine with the "Outer-UDP" encapsulation, so perhaps we should just stick with it. The only real argument against it is the overhead argument you mention, and some people argue that various tunneling techniques used in the Internet today already add lots of overhead. Plus one could use Robust Header Compression if this is really a problem. (*) The ID-LOC draft does not currently use ESP, but instead uses a "demux" header which specifies the protocol number of the following transport protocol. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 11:53:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fgp-0007jS-KI; Tue, 18 Dec 2007 11:53:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4fgo-0007iI-Hj for p2psip@ietf.org; Tue, 18 Dec 2007 11:53:06 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4fgo-0002lh-8N for p2psip@ietf.org; Tue, 18 Dec 2007 11:53:06 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBIGqrj9025608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2007 10:52:54 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBIGqr1c018732; Tue, 18 Dec 2007 08:52:53 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBIGqqxw018639; Tue, 18 Dec 2007 08:52:53 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 08:52:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) Date: Tue, 18 Dec 2007 08:52:51 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049A97@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <476796F5.1040207@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) Thread-Index: AchBWuWO2u1+zYgERrik2OUjXulBxgAO2Fgw References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca><20071218084807.4047C33C69@delta.rtfm.com> <476796F5.1040207@gmx.net> From: "Henderson, Thomas R" To: "Hannes Tschofenig" , "Eric Rescorla" X-OriginalArrivalTime: 18 Dec 2007 16:52:52.0332 (UTC) FILETIME=[6DD032C0:01C84196] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Tuesday, December 18, 2007 1:46 AM > To: Eric Rescorla > Cc: Henry Sinnreich; Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) >=20 > This was one of the concern raised when we looked in using=20 > HIP together=20 > with SIP a few years ago. > As a consequence we wrote a separate document to allow HIP to create=20 > SRTP security associations. > A student also implemented it. The interaction between the different=20 > layers wasn't easy. >=20 > Ciao > Hannes For reference: http://tools.ietf.org/html/draft-tschofenig-hiprg-hip-srtp-02 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 12:29:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gFj-0003B5-1W; Tue, 18 Dec 2007 12:29:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gFh-0002n5-BW for p2psip@ietf.org; Tue, 18 Dec 2007 12:29:09 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4gFf-0005aS-O1 for p2psip@ietf.org; Tue, 18 Dec 2007 12:29:09 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id DC3FA2EE7; Tue, 18 Dec 2007 19:29:06 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id C393C2E69; Tue, 18 Dec 2007 19:28:59 +0200 (EET) Date: Tue, 18 Dec 2007 19:28:59 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <20071217164438.38F0433C53@delta.rtfm.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> <20071217164438.38F0433C53@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 17 Dec 2007, Eric Rescorla wrote: Hi Eric, > At Mon, 17 Dec 2007 18:04:42 +0200 (EET), > Miika Komu wrote: >> The same way as without public keys. I fail to see the problem here. > > I don't even understand what you're proposing any more. > > If you want to describe a specific proposal, I'll be happy to address > its merits. This is one example how it could work: You connect with your web browser to the enrollment server. The DNS contains the HIT of the enrollment server, which triggers a base exchange with the enrollment server and makes the HTTP(S) connection to use HIP. You fill in a web form and give your bank card number for the enrollment server. The web server software stores the HIT and the bank card number for enrollment purposes. From this on, we could have two alternative design solutions: a) When the new peer joins the network, DHT nodes that have been already accepted in the network will ask the enrollment server if the new peer has enrolled successfully. b) The enrollment server could give the new peer a certificate which the peer could be using directly when actually joining the DHT. I believe approach (a) proves my original point that you can use host-generated DHT identifiers without certificates. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 12:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gMs-0001dw-IG; Tue, 18 Dec 2007 12:36:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gMr-0001dp-Fa for p2psip@ietf.org; Tue, 18 Dec 2007 12:36:33 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4gMq-0004Pk-WD for p2psip@ietf.org; Tue, 18 Dec 2007 12:36:33 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.13.8/8.13.8) with ESMTP id lBIHZxd6031154; Tue, 18 Dec 2007 09:35:59 -0800 (PST) (envelope-from ekr@networkresonance.com) Message-Id: <200712181735.lBIHZxd6031154@romeo.rtfm.com> Date: Tue, 18 Dec 2007 09:35:59 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> <20071217164438.38F0433C53@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 18 Dec 2007 19:28:59 +0200 (EET), Miika Komu wrote: > > On Mon, 17 Dec 2007, Eric Rescorla wrote: > > Hi Eric, > > > At Mon, 17 Dec 2007 18:04:42 +0200 (EET), > > Miika Komu wrote: > >> The same way as without public keys. I fail to see the problem here. > > > > I don't even understand what you're proposing any more. > > > > If you want to describe a specific proposal, I'll be happy to address > > its merits. > > This is one example how it could work: > > You connect with your web browser to the enrollment server. The DNS > contains the HIT of the enrollment server, which triggers a base > exchange with the enrollment server and makes the HTTP(S) connection to > use HIP. You fill in a web form and give your bank card number for the > enrollment server. The web server software stores the HIT and the bank > card number for enrollment purposes. From this on, we could have two > alternative design solutions: > > a) When the new peer joins the network, DHT nodes that have been already > accepted in the network will ask the enrollment server if the new peer > has enrolled successfully. > b) The enrollment server could give the new peer a certificate which the > peer could be using directly when actually joining the DHT. > > I believe approach (a) proves my original point that you can use > host-generated DHT identifiers without certificates. Uh, sure, if you're willing to have the enrollment server online 24-7 acting as a real-time CA. It's hard to see how that's practical operationally. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 12:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gMz-0001of-QU; Tue, 18 Dec 2007 12:36:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gMx-0001iD-S6 for p2psip@ietf.org; Tue, 18 Dec 2007 12:36:39 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4gMx-0004Py-DR for p2psip@ietf.org; Tue, 18 Dec 2007 12:36:39 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1J4gMp-0002oP-JX; Tue, 18 Dec 2007 11:36:31 -0600 From: "Brian Rosen" To: "'Miika Komu'" , "'Eric Rescorla'" References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><20071212160813.3863033C6D@delta.rtfm.com><20071213163033.6EE1433C72@delta.rtfm.com><20071213205251.548E933C6D@delta.rtfm.com><20071214145748.E37DF33C6D@delta.rtfm.com><20071217164438.38F0433C53@delta.rtfm.com> Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Tue, 18 Dec 2007 12:36:34 -0500 Message-ID: <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchBm36csIINV1pQS8Ki6lUdAMJjagAAKAgQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org While a) proves your point, I think we're not really interested in a solution that requires the enrollment server to be reachable by any peer to determine admittance to the overlay. It's one thing to need to be able to reach the enrollment service once to enroll; it's quite another to require it to be available to join the overlay. Brian > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi] > Sent: Tuesday, December 18, 2007 12:29 PM > To: Eric Rescorla > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > On Mon, 17 Dec 2007, Eric Rescorla wrote: > > Hi Eric, > > > At Mon, 17 Dec 2007 18:04:42 +0200 (EET), > > Miika Komu wrote: > >> The same way as without public keys. I fail to see the problem here. > > > > I don't even understand what you're proposing any more. > > > > If you want to describe a specific proposal, I'll be happy to address > > its merits. > > This is one example how it could work: > > You connect with your web browser to the enrollment server. The DNS > contains the HIT of the enrollment server, which triggers a base > exchange with the enrollment server and makes the HTTP(S) connection to > use HIP. You fill in a web form and give your bank card number for the > enrollment server. The web server software stores the HIT and the bank > card number for enrollment purposes. From this on, we could have two > alternative design solutions: > > a) When the new peer joins the network, DHT nodes that have been already > accepted in the network will ask the enrollment server if the new peer > has enrolled successfully. > b) The enrollment server could give the new peer a certificate which the > peer could be using directly when actually joining the DHT. > > I believe approach (a) proves my original point that you can use > host-generated DHT identifiers without certificates. > > -- > Miika Komu http://www.iki.fi/miika/ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 12:45:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gVy-0006co-Vy; Tue, 18 Dec 2007 12:45:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gVy-0006ci-9y for p2psip@ietf.org; Tue, 18 Dec 2007 12:45:58 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4gVx-0004gr-Lf for p2psip@ietf.org; Tue, 18 Dec 2007 12:45:58 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A53572D19; Tue, 18 Dec 2007 19:45:56 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 415182D0A; Tue, 18 Dec 2007 19:45:49 +0200 (EET) Date: Tue, 18 Dec 2007 19:45:49 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Brian Rosen Subject: RE: [P2PSIP] Re: HIP pros and cons In-Reply-To: <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><20071212160813.3863033C6D@delta.rtfm.com><20071213163033.6EE1433C72@delta.rtfm.com><20071213205251.548E933C6D@delta.rtfm.com><20071214145748.E37DF33C6D@delta.rtfm.com><20071217164438.38F0433C53@delta.rtfm.com> <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Tue, 18 Dec 2007, Brian Rosen wrote: Hi Brian, thanks for the feedback. It seems like the alternative b is mandatory for p2p-sip. Otherwise, then I don't see how you are going to avoid the use of cryptographic certificates without compromising dht identifier security and revocation. In alternative b, it is still possible to use host generated dht key identifiers. > > While a) proves your point, I think we're not really interested in a > solution that requires the enrollment server to be reachable by any peer to > determine admittance to the overlay. It's one thing to need to be able to > reach the enrollment service once to enroll; it's quite another to require > it to be available to join the overlay. > > Brian > >> -----Original Message----- >> From: Miika Komu [mailto:miika@iki.fi] >> Sent: Tuesday, December 18, 2007 12:29 PM >> To: Eric Rescorla >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Re: HIP pros and cons >> >> On Mon, 17 Dec 2007, Eric Rescorla wrote: >> >> Hi Eric, >> >>> At Mon, 17 Dec 2007 18:04:42 +0200 (EET), >>> Miika Komu wrote: >>>> The same way as without public keys. I fail to see the problem here. >>> >>> I don't even understand what you're proposing any more. >>> >>> If you want to describe a specific proposal, I'll be happy to address >>> its merits. >> >> This is one example how it could work: >> >> You connect with your web browser to the enrollment server. The DNS >> contains the HIT of the enrollment server, which triggers a base >> exchange with the enrollment server and makes the HTTP(S) connection to >> use HIP. You fill in a web form and give your bank card number for the >> enrollment server. The web server software stores the HIT and the bank >> card number for enrollment purposes. From this on, we could have two >> alternative design solutions: >> >> a) When the new peer joins the network, DHT nodes that have been already >> accepted in the network will ask the enrollment server if the new peer >> has enrolled successfully. >> b) The enrollment server could give the new peer a certificate which the >> peer could be using directly when actually joining the DHT. >> >> I believe approach (a) proves my original point that you can use >> host-generated DHT identifiers without certificates. >> >> -- >> Miika Komu http://www.iki.fi/miika/ >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 12:54:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gdp-0000Wi-VR; Tue, 18 Dec 2007 12:54:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gdo-0000Wa-CQ for p2psip@ietf.org; Tue, 18 Dec 2007 12:54:04 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4gdo-000501-0Q for p2psip@ietf.org; Tue, 18 Dec 2007 12:54:04 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 854972E0F; Tue, 18 Dec 2007 19:54:03 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 897CF2DDF; Tue, 18 Dec 2007 19:53:56 +0200 (EET) Date: Tue, 18 Dec 2007 19:53:56 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Ingmar Baumgart Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <4766789F.5040809@tm.uka.de> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <4766789F.5040809@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 17 Dec 2007, Ingmar Baumgart wrote: > Miika Komu wrote: >> At least HIPL implements it by using the deployed i3 network in >> planetlab. If I recall correctly, HIP packets are transported over i3 >> headers through the overlay and ESP packets are sent directly between >> the peers. We are currently integrating STUN/ICE with "normal-mode" HIP >> and later with Hi3. The implementations are available at: >> >> http://infrahip.hiit.fi/ >> http://www.openhip.org/ >> http://www.hip4inter.net/ > > Which ICE library (PJNATH, Nice,...) do you use in your HIP implementation? Hi Ingmar, currently PJNATH. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 13:04:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gne-0005nj-UJ; Tue, 18 Dec 2007 13:04:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gnd-0005lN-8T for p2psip@ietf.org; Tue, 18 Dec 2007 13:04:13 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4gnc-0005Sg-PB for p2psip@ietf.org; Tue, 18 Dec 2007 13:04:13 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 377F92E3C; Tue, 18 Dec 2007 20:04:12 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 3FB6C2E97; Tue, 18 Dec 2007 20:04:00 +0200 (EET) Date: Tue, 18 Dec 2007 20:04:00 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [P2PSIP] HIP performance concerns (was HIP pros and cons) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049A95@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei><4766A124.4080906@uni-tuebingen.de> <6191EB54-4A0F-4D97-9F26-CEEE88CBB2B7@magma.ca> <77F357662F8BFA4CA7074B0410171B6D04049A95@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 17 Dec 2007, Henderson, Thomas R wrote: > >>> >>> - if you do mobility with HIP, you will need to update the IPSec >>> SAs in the kernel when a handover occurs. Is that correct? >> How well >>> does this work? Has there been some experiments that show that HIP >>> can provide seamless mobility? If yes, please provide a reference. >> >> For "basic HIP", I understand the answer is no. >> For other forms of HIP, I believe the answer will be the same. >> However, I will say that I am not a security expert, nor am I an >> expert on HIP. > > For basic HIP, the answer is yes; the SAs are updated whenever the > locator changes so that the outer header is correct. The SAs may often > be rekeyed at the same time. > > We have been doing so-called vertical handoffs (across access > technologies) at Boeing using HIP, including voice handoffs. I would > not call it seamless, though; it is a layer-3 end-to-end handoff. The > handoff latency has several components, including round-trip time, time > to detect a path change event, and signature operations. I don't have > any recent results to cite, but we published some results from an early > HIP implementation at the 2003 IEEE WCNC conference [*], where we found > that HIP readdressing events on Pentium II 266 MHz machines with > software encryption took less than a second to complete. > > Tom > > [*] Henderson, T.R., J.M. Ahrenholz, and J.H. Kim, " Experience with the > Host Identity Protocol for Secure Host Mobility and Multihoming," IEEE > Wireless Communications and Networking Conference (WCNC), New Orleans, > March 2003. I think the other results from HIP-based mobility are also quite positive: http://user.informatik.uni-goettingen.de/~mobiarch/2007/Khurri_HIP.pdf http://users.tkk.fi/~jylitalo/publications/ISC04-Ylitalo-et-al.pdf -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 13:08:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gsE-0003zb-DM; Tue, 18 Dec 2007 13:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4gsC-0003uY-K3 for p2psip@ietf.org; Tue, 18 Dec 2007 13:08:56 -0500 Received: from smtp03.bis.na.blackberry.com ([216.9.248.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4gsA-0006pF-OH for p2psip@ietf.org; Tue, 18 Dec 2007 13:08:56 -0500 Received: from bxe034.bisx.prod.on.blackberry (bxe034.bisx.prod.on.blackberry [172.20.225.53]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id lBIHDqqx031389; Tue, 18 Dec 2007 18:08:51 GMT X-rim-org-msg-ref-id: 1717010584 Message-ID: <1717010584-1198001331-cardhu_decombobulator_blackberry.rim.net-187882339-@bxe034.bisx.prod.on.blackberry> X-Priority: Normal References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com><20071212160813.3863033C6D@delta.rtfm.com><20071213163033.6EE1433C72@delta.rtfm.com><20071213205251.548E933C6D@delta.rtfm.com><20071214145748.E37DF33C6D@delta.rtfm.com><20071217164438.38F0433C53@delta.rtfm.com><02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> In-Reply-To: <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> Sensitivity: Normal Importance: Normal To: "Brian Rosen" , "'Miika Komu'" , "'Eric Rescorla'" Subject: Re: [P2PSIP] Re: HIP pros and cons From: "=?utf-8?B?RGFuIFlvcms=?=" Date: Tue, 18 Dec 2007 18:08:56 +0000 MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dyork@voxeo.com List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385066043==" Errors-To: p2psip-bounces@ietf.org --===============0385066043== Content-Transfer-Encoding: base64 Content-Type: text/plain VHdvIHdvcmRzOiAiU2t5cGUgb3V0YWdlIi4gQXMgYmVzdCB3ZSBjYW4gdW5kZXJzdGFuZCwgKGEp IGlzIHNpbWlsYXIgdG8gdGhlIGFyY2hpdGVjdHVyZSB1c2VkIGJ5IFNreXBlLiBBIFNreXBlIGNs aWVudCBtdXN0IGJlIGFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbi9l bnJvbGxtZW50IHNlcnZlcnMgdG8gYmUgYWJsZSB0byBhY2Nlc3MgdGhlIFNreXBlIFAyUCBjbG91 ZC4gV2hlbiB0aG9zZSBzZXJ2ZXJzIHRoZW4gYmVjYW1lIGluYWNjZXNzaWJsZSwgdGhlIHNjZW5h cmlvIHVuZm9sZGVkIHRoYXQgbGVkIHRvIHRoZSAyLWRheSBvdXRhZ2UuDQoNCkkgZG9uJ3Qgd2Fu dCB0byBkZWJhdGUgU2t5cGUncyBvdXRhZ2UsIGJ1dCBteSBwb2ludCBpcyB0aGF0IEkgd291bGQg dGhpbmsgd2Ugd2FudCB0byBhdm9pZCBhbnl0aGluZyB0aGF0IGludHJvZHVjZXMgYSAic2luZ2xl IHBvaW50LW9mLWZhaWx1cmUiIHdoaWNoIChhKSBzZWVtcyB0byBtZSB0byBkby4gSXQgc2VlbXMg dG8gbWUgdG8gYmUgdGhlIG9wcG9zaXRlIG9mIHdoYXQgd2UgYXJlIHRyeWluZyB0byBkbyB3aXRo IFAyUCBTSVAuICANCg0KKFNvIEkgYWdyZWUgd2l0aCB0aGUgY29tbWVudHMgZnJvbSBCcmlhbiBh bmQgRUtSIHRoYXQgKGEpIGlzIG5vdCBhZHZpc2FibGUuKQ0KDQpNeSAyIGNlbnRzLA0KRGFuDQot LSANCkRhbiBZb3JrLCBDSVNTUCwgRGlyZWN0b3Igb2YgRW1lcmdpbmcgQ29tbXVuaWNhdGlvbiBU ZWNobm9sb2d5DQpPZmZpY2Ugb2YgdGhlIENUTyAgICBWb3hlbyBDb3Jwb3JhdGlvbiAgICAgZHlv cmtAdm94ZW8uY29tDQpQaG9uZTogKzEtNDA3LTQ1NS01ODU5ICBTa3lwZTogZGFueW9yayAgaHR0 cDovL3d3dy52b3hlby5jb20NCkJsb2dzOiBodHRwOi8vYmxvZ3Mudm94ZW8uY29tICBodHRwOi8v d3d3LmRpc3J1cHRpdmV0ZWxlcGhvbnkuY29tDQoNCkJyaW5nIHlvdXIgd2ViIGFwcGxpY2F0aW9u cyB0byB0aGUgcGhvbmUuDQpGaW5kIG91dCBob3cgYXQgaHR0cDovL2V2b2x1dGlvbi52b3hlby5j b20NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiQnJpYW4gUm9zZW4i IDxickBicmlhbnJvc2VuLm5ldD4NCg0KRGF0ZTogVHVlLCAxOCBEZWMgMjAwNyAxMjozNjozNCAN ClRvOiInTWlpa2EgS29tdSciIDxtaWlrYUBpa2kuZmk+LCAiJ0VyaWMgUmVzY29ybGEnIiA8ZWty QG5ldHdvcmtyZXNvbmFuY2UuY29tPg0KQ2M6cDJwc2lwQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W1AyUFNJUF0gUmU6IEhJUCBwcm9zIGFuZCBjb25zDQoNCg0KPGFzIGluZGl2aWR1YWw+DQpXaGls ZSBhKSBwcm92ZXMgeW91ciBwb2ludCwgSSB0aGluayB3ZSdyZSBub3QgcmVhbGx5IGludGVyZXN0 ZWQgaW4gYQ0Kc29sdXRpb24gdGhhdCByZXF1aXJlcyB0aGUgZW5yb2xsbWVudCBzZXJ2ZXIgdG8g YmUgcmVhY2hhYmxlIGJ5IGFueSBwZWVyIHRvDQpkZXRlcm1pbmUgYWRtaXR0YW5jZSB0byB0aGUg b3ZlcmxheS4gIEl0J3Mgb25lIHRoaW5nIHRvIG5lZWQgdG8gYmUgYWJsZSB0bw0KcmVhY2ggdGhl IGVucm9sbG1lbnQgc2VydmljZSBvbmNlIHRvIGVucm9sbDsgaXQncyBxdWl0ZSBhbm90aGVyIHRv IHJlcXVpcmUNCml0IHRvIGJlIGF2YWlsYWJsZSB0byBqb2luIHRoZSBvdmVybGF5Lg0KDQpCcmlh bg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1paWthIEtvbXUgW21h aWx0bzptaWlrYUBpa2kuZmldDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAyMDA3IDEy OjI5IFBNDQo+IFRvOiBFcmljIFJlc2NvcmxhDQo+IENjOiBwMnBzaXBAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtQMlBTSVBdIFJlOiBISVAgcHJvcyBhbmQgY29ucw0KPg0KPiBPbiBNb24sIDE3 IERlYyAyMDA3LCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPg0KPiBIaSBFcmljLA0KPg0KPiA+IEF0 IE1vbiwgMTcgRGVjIDIwMDcgMTg6MDQ6NDIgKzAyMDAgKEVFVCksDQo+ID4gTWlpa2EgS29tdSB3 cm90ZToNCj4gPj4gVGhlIHNhbWUgd2F5IGFzIHdpdGhvdXQgcHVibGljIGtleXMuIEkgZmFpbCB0 byBzZWUgdGhlIHByb2JsZW0gaGVyZS4NCj4gPg0KPiA+IEkgZG9uJ3QgZXZlbiB1bmRlcnN0YW5k IHdoYXQgeW91J3JlIHByb3Bvc2luZyBhbnkgbW9yZS4NCj4gPg0KPiA+IElmIHlvdSB3YW50IHRv IGRlc2NyaWJlIGEgc3BlY2lmaWMgcHJvcG9zYWwsIEknbGwgYmUgaGFwcHkgdG8gYWRkcmVzcw0K PiA+IGl0cyBtZXJpdHMuDQo+DQo+IFRoaXMgaXMgb25lIGV4YW1wbGUgaG93IGl0IGNvdWxkIHdv cms6DQo+DQo+IFlvdSBjb25uZWN0IHdpdGggeW91ciB3ZWIgYnJvd3NlciB0byB0aGUgZW5yb2xs bWVudCBzZXJ2ZXIuIFRoZSBETlMNCj4gY29udGFpbnMgdGhlIEhJVCBvZiB0aGUgZW5yb2xsbWVu dCBzZXJ2ZXIsIHdoaWNoIHRyaWdnZXJzIGEgYmFzZQ0KPiBleGNoYW5nZSB3aXRoIHRoZSBlbnJv bGxtZW50IHNlcnZlciBhbmQgbWFrZXMgdGhlIEhUVFAoUykgY29ubmVjdGlvbiB0bw0KPiB1c2Ug SElQLiBZb3UgZmlsbCBpbiBhIHdlYiBmb3JtIGFuZCBnaXZlIHlvdXIgYmFuayBjYXJkIG51bWJl ciBmb3IgdGhlDQo+IGVucm9sbG1lbnQgc2VydmVyLiBUaGUgd2ViIHNlcnZlciBzb2Z0d2FyZSBz dG9yZXMgdGhlIEhJVCBhbmQgdGhlIGJhbmsNCj4gY2FyZCBudW1iZXIgZm9yIGVucm9sbG1lbnQg cHVycG9zZXMuIEZyb20gdGhpcyBvbiwgd2UgY291bGQgaGF2ZSB0d28NCj4gYWx0ZXJuYXRpdmUg ZGVzaWduIHNvbHV0aW9uczoNCj4NCj4gYSkgV2hlbiB0aGUgbmV3IHBlZXIgam9pbnMgdGhlIG5l dHdvcmssIERIVCBub2RlcyB0aGF0IGhhdmUgYmVlbiBhbHJlYWR5DQo+ICAgICBhY2NlcHRlZCBp biB0aGUgbmV0d29yayB3aWxsIGFzayB0aGUgZW5yb2xsbWVudCBzZXJ2ZXIgaWYgdGhlIG5ldyBw ZWVyDQo+ICAgICBoYXMgZW5yb2xsZWQgc3VjY2Vzc2Z1bGx5Lg0KPiBiKSBUaGUgZW5yb2xsbWVu dCBzZXJ2ZXIgY291bGQgZ2l2ZSB0aGUgbmV3IHBlZXIgYSBjZXJ0aWZpY2F0ZSB3aGljaCB0aGUN Cj4gICAgIHBlZXIgY291bGQgYmUgdXNpbmcgZGlyZWN0bHkgd2hlbiBhY3R1YWxseSBqb2luaW5n IHRoZSBESFQuDQo+DQo+IEkgYmVsaWV2ZSBhcHByb2FjaCAoYSkgcHJvdmVzIG15IG9yaWdpbmFs IHBvaW50IHRoYXQgeW91IGNhbiB1c2UNCj4gaG9zdC1nZW5lcmF0ZWQgREhUIGlkZW50aWZpZXJz IHdpdGhvdXQgY2VydGlmaWNhdGVzLg0KPg0KPiAtLQ0KPiBNaWlrYSBLb211ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5pa2kuZmkvbWlpa2EvDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJ UCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0K --===============0385066043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0385066043==-- From p2psip-bounces@ietf.org Tue Dec 18 13:19:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4h22-0006ph-Gz; Tue, 18 Dec 2007 13:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4h21-0006pb-Iu for p2psip@ietf.org; Tue, 18 Dec 2007 13:19:05 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4h21-0007Dz-68 for p2psip@ietf.org; Tue, 18 Dec 2007 13:19:05 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (8.13.8/8.13.8) with ESMTP id lBIIIWv9003612; Tue, 18 Dec 2007 10:18:33 -0800 (PST) (envelope-from ekr@networkresonance.com) Message-Id: <200712181818.lBIIIWv9003612@romeo.rtfm.com> Date: Tue, 18 Dec 2007 10:18:32 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> <20071217164438.38F0433C53@delta.rtfm.com> <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 18 Dec 2007 19:45:49 +0200 (EET), Miika Komu wrote: > > On Tue, 18 Dec 2007, Brian Rosen wrote: > > Hi Brian, > > thanks for the feedback. It seems like the alternative b is mandatory for > p2p-sip. Otherwise, then I don't see how you are going to avoid the use of > cryptographic certificates without compromising dht identifier security > and revocation. > > In alternative b, it is still possible to use host generated dht key > identifiers. Again, not if you want to use them as the locations in the DHT, because then you get chosen location attacks. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 15:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jD0-0006D9-8X; Tue, 18 Dec 2007 15:38:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jCz-0006Cw-JT for p2psip@ietf.org; Tue, 18 Dec 2007 15:38:33 -0500 Received: from quinthar.com ([72.52.120.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4jCy-0004WY-Ty for p2psip@ietf.org; Tue, 18 Dec 2007 15:38:33 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Tue, 18 Dec 2007 12:38:28 -0800 From: "David Barrett" To: "'Brian Rosen'" , "'Miika Komu'" , "'Eric Rescorla'" Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Tue, 18 Dec 2007 12:38:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> Thread-Index: AchBm36csIINV1pQS8Ki6lUdAMJjagAAKAgQAAX+a1A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: Just curious, if my laptop gets stolen, will P2PSIP provide any facility for me to prevent the thief from making and receiving calls in my name? If so, how will that be done without a 24/7 realtime check to either a centralized or federated server? If we assume there's some kind of password, then that means there's some sort of password check. If we assume we can ban clients, then we need to somehow record which clients are banned and check that. If we can revoke certificates, then there's a certificate revocation list. Is there any way to support this seemingly obvious requirement -- the requirement that I can prevent a thief from forever, undetectably impersonating me -- without some sort of central, realtime, 24/7 lookup? Or is the answer "to be determined" or "not our problem; we punt this to another layer"? -david > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, December 18, 2007 9:37 AM > To: 'Miika Komu'; 'Eric Rescorla' > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] Re: HIP pros and cons > > > While a) proves your point, I think we're not really interested in a > solution that requires the enrollment server to be reachable by any peer > to > determine admittance to the overlay. It's one thing to need to be able to > reach the enrollment service once to enroll; it's quite another to require > it to be available to join the overlay. > > Brian > > > -----Original Message----- > > From: Miika Komu [mailto:miika@iki.fi] > > Sent: Tuesday, December 18, 2007 12:29 PM > > To: Eric Rescorla > > Cc: p2psip@ietf.org > > Subject: Re: [P2PSIP] Re: HIP pros and cons > > > > On Mon, 17 Dec 2007, Eric Rescorla wrote: > > > > Hi Eric, > > > > > At Mon, 17 Dec 2007 18:04:42 +0200 (EET), > > > Miika Komu wrote: > > >> The same way as without public keys. I fail to see the problem here. > > > > > > I don't even understand what you're proposing any more. > > > > > > If you want to describe a specific proposal, I'll be happy to address > > > its merits. > > > > This is one example how it could work: > > > > You connect with your web browser to the enrollment server. The DNS > > contains the HIT of the enrollment server, which triggers a base > > exchange with the enrollment server and makes the HTTP(S) connection to > > use HIP. You fill in a web form and give your bank card number for the > > enrollment server. The web server software stores the HIT and the bank > > card number for enrollment purposes. From this on, we could have two > > alternative design solutions: > > > > a) When the new peer joins the network, DHT nodes that have been already > > accepted in the network will ask the enrollment server if the new > peer > > has enrolled successfully. > > b) The enrollment server could give the new peer a certificate which the > > peer could be using directly when actually joining the DHT. > > > > I believe approach (a) proves my original point that you can use > > host-generated DHT identifiers without certificates. > > > > -- > > Miika Komu > http://www.iki.fi/miika/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 15:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jPp-0005fp-NP; Tue, 18 Dec 2007 15:51:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jPo-0005ct-Ap for p2psip@ietf.org; Tue, 18 Dec 2007 15:51:48 -0500 Received: from quinthar.com ([72.52.120.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4jPn-00050x-Ih for p2psip@ietf.org; Tue, 18 Dec 2007 15:51:48 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Tue, 18 Dec 2007 12:51:40 -0800 From: "David Barrett" To: , "'Brian Rosen'" , "'Miika Komu'" , "'Eric Rescorla'" Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Tue, 18 Dec 2007 12:51:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1717010584-1198001331-cardhu_decombobulator_blackberry.rim.net-187882339-@bxe034.bisx.prod.on.blackberry> Thread-Index: AchBoRIkWwNVttOzSrCTHZur8r2YqgAE6Ddg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: The Skype outage demonstrates precisely the opposite of what you're claiming. Rather, it shows that inappropriate use of decentralization turns minor spikes into fatal calamities due to congestion-collapse scenarios. Had they simply authenticated everything globally, then a spike in login requests would result in a slowdown of logins for an hour or so, and that's it. But because they built a totally unnecessary p2p solution, the spike caused *days* of instability. Skype is the very example of why we should build central authentication. -david > -----Original Message----- > From: Dan York [mailto:dyork@voxeo.com] > Sent: Tuesday, December 18, 2007 10:09 AM > To: Brian Rosen; 'Miika Komu'; 'Eric Rescorla' > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > Two words: "Skype outage". As best we can understand, (a) is similar to > the architecture used by Skype. A Skype client must be able to communicate > with the authorization/enrollment servers to be able to access the Skype > P2P cloud. When those servers then became inaccessible, the scenario > unfolded that led to the 2-day outage. > > I don't want to debate Skype's outage, but my point is that I would think > we want to avoid anything that introduces a "single point-of-failure" > which (a) seems to me to do. It seems to me to be the opposite of what we > are trying to do with P2P SIP. > > (So I agree with the comments from Brian and EKR that (a) is not > advisable.) > > My 2 cents, > Dan > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Bring your web applications to the phone. > Find out how at http://evolution.voxeo.com > > > > -----Original Message----- > From: "Brian Rosen" > > Date: Tue, 18 Dec 2007 12:36:34 > To:"'Miika Komu'" , "'Eric Rescorla'" > > Cc:p2psip@ietf.org > Subject: RE: [P2PSIP] Re: HIP pros and cons > > > > While a) proves your point, I think we're not really interested in a > solution that requires the enrollment server to be reachable by any peer > to > determine admittance to the overlay. It's one thing to need to be able to > reach the enrollment service once to enroll; it's quite another to require > it to be available to join the overlay. > > Brian > > > -----Original Message----- > > From: Miika Komu [mailto:miika@iki.fi] > > Sent: Tuesday, December 18, 2007 12:29 PM > > To: Eric Rescorla > > Cc: p2psip@ietf.org > > Subject: Re: [P2PSIP] Re: HIP pros and cons > > > > On Mon, 17 Dec 2007, Eric Rescorla wrote: > > > > Hi Eric, > > > > > At Mon, 17 Dec 2007 18:04:42 +0200 (EET), > > > Miika Komu wrote: > > >> The same way as without public keys. I fail to see the problem here. > > > > > > I don't even understand what you're proposing any more. > > > > > > If you want to describe a specific proposal, I'll be happy to address > > > its merits. > > > > This is one example how it could work: > > > > You connect with your web browser to the enrollment server. The DNS > > contains the HIT of the enrollment server, which triggers a base > > exchange with the enrollment server and makes the HTTP(S) connection to > > use HIP. You fill in a web form and give your bank card number for the > > enrollment server. The web server software stores the HIT and the bank > > card number for enrollment purposes. From this on, we could have two > > alternative design solutions: > > > > a) When the new peer joins the network, DHT nodes that have been already > > accepted in the network will ask the enrollment server if the new > peer > > has enrolled successfully. > > b) The enrollment server could give the new peer a certificate which the > > peer could be using directly when actually joining the DHT. > > > > I believe approach (a) proves my original point that you can use > > host-generated DHT identifiers without certificates. > > > > -- > > Miika Komu > http://www.iki.fi/miika/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 16:12:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jjl-00028n-SQ; Tue, 18 Dec 2007 16:12:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jjk-0001zg-5T for p2psip@ietf.org; Tue, 18 Dec 2007 16:12:24 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4jjj-0005n9-Ft for p2psip@ietf.org; Tue, 18 Dec 2007 16:12:24 -0500 Received: from irtcluster02.cs.columbia.edu (irtcluster02.cs.columbia.edu [128.59.19.154]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lBILCJck017820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Dec 2007 16:12:20 -0500 (EST) Date: Tue, 18 Dec 2007 16:12:19 -0500 (EST) From: Salman Abdul Baset To: David Barrett Subject: RE: [P2PSIP] Re: HIP pros and cons In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Skype does not have a distributed authentication mechanism. Their p2p solution is for search and selecting voice/video relays. -s On Tue, 18 Dec 2007, David Barrett wrote: > The Skype outage demonstrates precisely the opposite of what you're > claiming. Rather, it shows that inappropriate use of decentralization turns > minor spikes into fatal calamities due to congestion-collapse scenarios. > > Had they simply authenticated everything globally, then a spike in login > requests would result in a slowdown of logins for an hour or so, and that's > it. > > But because they built a totally unnecessary p2p solution, the spike caused > *days* of instability. > > Skype is the very example of why we should build central authentication. > > -david > >> -----Original Message----- >> From: Dan York [mailto:dyork@voxeo.com] >> Sent: Tuesday, December 18, 2007 10:09 AM >> To: Brian Rosen; 'Miika Komu'; 'Eric Rescorla' >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Re: HIP pros and cons >> >> Two words: "Skype outage". As best we can understand, (a) is similar to >> the architecture used by Skype. A Skype client must be able to communicate >> with the authorization/enrollment servers to be able to access the Skype >> P2P cloud. When those servers then became inaccessible, the scenario >> unfolded that led to the 2-day outage. >> >> I don't want to debate Skype's outage, but my point is that I would think >> we want to avoid anything that introduces a "single point-of-failure" >> which (a) seems to me to do. It seems to me to be the opposite of what we >> are trying to do with P2P SIP. >> >> (So I agree with the comments from Brian and EKR that (a) is not >> advisable.) >> >> My 2 cents, >> Dan >> -- >> Dan York, CISSP, Director of Emerging Communication Technology >> Office of the CTO Voxeo Corporation dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >> >> Bring your web applications to the phone. >> Find out how at http://evolution.voxeo.com >> >> >> >> -----Original Message----- >> From: "Brian Rosen" >> >> Date: Tue, 18 Dec 2007 12:36:34 >> To:"'Miika Komu'" , "'Eric Rescorla'" >> >> Cc:p2psip@ietf.org >> Subject: RE: [P2PSIP] Re: HIP pros and cons >> >> >> >> While a) proves your point, I think we're not really interested in a >> solution that requires the enrollment server to be reachable by any peer >> to >> determine admittance to the overlay. It's one thing to need to be able to >> reach the enrollment service once to enroll; it's quite another to require >> it to be available to join the overlay. >> >> Brian >> >>> -----Original Message----- >>> From: Miika Komu [mailto:miika@iki.fi] >>> Sent: Tuesday, December 18, 2007 12:29 PM >>> To: Eric Rescorla >>> Cc: p2psip@ietf.org >>> Subject: Re: [P2PSIP] Re: HIP pros and cons >>> >>> On Mon, 17 Dec 2007, Eric Rescorla wrote: >>> >>> Hi Eric, >>> >>>> At Mon, 17 Dec 2007 18:04:42 +0200 (EET), >>>> Miika Komu wrote: >>>>> The same way as without public keys. I fail to see the problem here. >>>> >>>> I don't even understand what you're proposing any more. >>>> >>>> If you want to describe a specific proposal, I'll be happy to address >>>> its merits. >>> >>> This is one example how it could work: >>> >>> You connect with your web browser to the enrollment server. The DNS >>> contains the HIT of the enrollment server, which triggers a base >>> exchange with the enrollment server and makes the HTTP(S) connection to >>> use HIP. You fill in a web form and give your bank card number for the >>> enrollment server. The web server software stores the HIT and the bank >>> card number for enrollment purposes. From this on, we could have two >>> alternative design solutions: >>> >>> a) When the new peer joins the network, DHT nodes that have been already >>> accepted in the network will ask the enrollment server if the new >> peer >>> has enrolled successfully. >>> b) The enrollment server could give the new peer a certificate which the >>> peer could be using directly when actually joining the DHT. >>> >>> I believe approach (a) proves my original point that you can use >>> host-generated DHT identifiers without certificates. >>> >>> -- >>> Miika Komu >> http://www.iki.fi/miika/ >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 16:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jm1-0000L4-JF; Tue, 18 Dec 2007 16:14:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jm0-0000Kx-S7 for p2psip@ietf.org; Tue, 18 Dec 2007 16:14:44 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4jm0-0005qj-84 for p2psip@ietf.org; Tue, 18 Dec 2007 16:14:44 -0500 Received: from p54a00ad9.dip0.t-ipconnect.de ([84.160.10.217] helo=[192.168.178.20]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J4jl7-0000gY-Iu; Tue, 18 Dec 2007 22:13:51 +0100 Message-ID: <476837F7.8030608@uni-tuebingen.de> Date: Tue, 18 Dec 2007 22:13:27 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] Re: HIP pros and cons References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi David, David Barrett wrote: > Just curious, if my laptop gets stolen, will P2PSIP provide any facility for > me to prevent the thief from making and receiving calls in my name? Once you have a certificate that you have received from the enrollment server, you can protect the private key that belongs to the certificate with a password on your local machine. So nobody will be able to steal your identity (well, except with a dictionary attack on your password). You don't need to contact one of the login servers here, except for verifying whether a peer certificate is in the revocation list. Certificate revocation is indeed a problem. Cheers, Ali > If so, how will that be done without a 24/7 realtime check to either a > centralized or federated server? > If we assume there's some kind of password, then that means there's some > sort of password check. If we assume we can ban clients, then we need to > somehow record which clients are banned and check that. If we can revoke > certificates, then there's a certificate revocation list. > > Is there any way to support this seemingly obvious requirement -- the > requirement that I can prevent a thief from forever, undetectably > impersonating me -- without some sort of central, realtime, 24/7 lookup? > > Or is the answer "to be determined" or "not our problem; we punt this to > another layer"? > > -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 16:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4k0V-0001Ud-8U; Tue, 18 Dec 2007 16:29:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4k0T-0001UQ-Hj for p2psip@ietf.org; Tue, 18 Dec 2007 16:29:41 -0500 Received: from quinthar.com ([72.52.120.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4k0S-0007kE-MC for p2psip@ietf.org; Tue, 18 Dec 2007 16:29:41 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Tue, 18 Dec 2007 13:29:35 -0800 From: "David Barrett" To: "'Salman Abdul Baset'" Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Tue, 18 Dec 2007 13:29:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AchBuq/YPgS06gjiS/ma/ml9Wzjc2AAAJlLw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: Ah, I'm sorry, you're right -- authentication wasn't the problem, it was that the network couldn't reform after the loss of all the supernodes. So the specific lesson from Skype isn't about lack of centralized authentication capacity (which -- you're right -- had nothing to do with the problem), but rather the unnecessary use of supernodes for search/rendezvous leading to a congestion collapse scenario. -david > -----Original Message----- > From: Salman Abdul Baset [mailto:salman@cs.columbia.edu] > Sent: Tuesday, December 18, 2007 1:12 PM > To: David Barrett > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] Re: HIP pros and cons > > Skype does not have a distributed authentication mechanism. Their p2p > solution is for search and selecting voice/video relays. > -s > > On Tue, 18 Dec 2007, David Barrett wrote: > > > The Skype outage demonstrates precisely the opposite of what you're > > claiming. Rather, it shows that inappropriate use of decentralization > turns > > minor spikes into fatal calamities due to congestion-collapse scenarios. > > > > Had they simply authenticated everything globally, then a spike in login > > requests would result in a slowdown of logins for an hour or so, and > that's > > it. > > > > But because they built a totally unnecessary p2p solution, the spike > caused > > *days* of instability. > > > > Skype is the very example of why we should build central authentication. > > > > -david > > > >> -----Original Message----- > >> From: Dan York [mailto:dyork@voxeo.com] > >> Sent: Tuesday, December 18, 2007 10:09 AM > >> To: Brian Rosen; 'Miika Komu'; 'Eric Rescorla' > >> Cc: p2psip@ietf.org > >> Subject: Re: [P2PSIP] Re: HIP pros and cons > >> > >> Two words: "Skype outage". As best we can understand, (a) is similar to > >> the architecture used by Skype. A Skype client must be able to > communicate > >> with the authorization/enrollment servers to be able to access the > Skype > >> P2P cloud. When those servers then became inaccessible, the scenario > >> unfolded that led to the 2-day outage. > >> > >> I don't want to debate Skype's outage, but my point is that I would > think > >> we want to avoid anything that introduces a "single point-of-failure" > >> which (a) seems to me to do. It seems to me to be the opposite of what > we > >> are trying to do with P2P SIP. > >> > >> (So I agree with the comments from Brian and EKR that (a) is not > >> advisable.) > >> > >> My 2 cents, > >> Dan > >> -- > >> Dan York, CISSP, Director of Emerging Communication Technology > >> Office of the CTO Voxeo Corporation dyork@voxeo.com > >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > >> > >> Bring your web applications to the phone. > >> Find out how at http://evolution.voxeo.com > >> > >> > >> > >> -----Original Message----- > >> From: "Brian Rosen" > >> > >> Date: Tue, 18 Dec 2007 12:36:34 > >> To:"'Miika Komu'" , "'Eric Rescorla'" > >> > >> Cc:p2psip@ietf.org > >> Subject: RE: [P2PSIP] Re: HIP pros and cons > >> > >> > >> > >> While a) proves your point, I think we're not really interested in a > >> solution that requires the enrollment server to be reachable by any > peer > >> to > >> determine admittance to the overlay. It's one thing to need to be able > to > >> reach the enrollment service once to enroll; it's quite another to > require > >> it to be available to join the overlay. > >> > >> Brian > >> > >>> -----Original Message----- > >>> From: Miika Komu [mailto:miika@iki.fi] > >>> Sent: Tuesday, December 18, 2007 12:29 PM > >>> To: Eric Rescorla > >>> Cc: p2psip@ietf.org > >>> Subject: Re: [P2PSIP] Re: HIP pros and cons > >>> > >>> On Mon, 17 Dec 2007, Eric Rescorla wrote: > >>> > >>> Hi Eric, > >>> > >>>> At Mon, 17 Dec 2007 18:04:42 +0200 (EET), > >>>> Miika Komu wrote: > >>>>> The same way as without public keys. I fail to see the problem here. > >>>> > >>>> I don't even understand what you're proposing any more. > >>>> > >>>> If you want to describe a specific proposal, I'll be happy to address > >>>> its merits. > >>> > >>> This is one example how it could work: > >>> > >>> You connect with your web browser to the enrollment server. The DNS > >>> contains the HIT of the enrollment server, which triggers a base > >>> exchange with the enrollment server and makes the HTTP(S) connection > to > >>> use HIP. You fill in a web form and give your bank card number for the > >>> enrollment server. The web server software stores the HIT and the bank > >>> card number for enrollment purposes. From this on, we could have two > >>> alternative design solutions: > >>> > >>> a) When the new peer joins the network, DHT nodes that have been > already > >>> accepted in the network will ask the enrollment server if the new > >> peer > >>> has enrolled successfully. > >>> b) The enrollment server could give the new peer a certificate which > the > >>> peer could be using directly when actually joining the DHT. > >>> > >>> I believe approach (a) proves my original point that you can use > >>> host-generated DHT identifiers without certificates. > >>> > >>> -- > >>> Miika Komu > >> http://www.iki.fi/miika/ > >>> > >>> _______________________________________________ > >>> P2PSIP mailing list > >>> P2PSIP@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/p2psip > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Dec 18 16:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4k5p-0003IG-Hm; Tue, 18 Dec 2007 16:35:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4k5o-0003I9-DT for p2psip@ietf.org; Tue, 18 Dec 2007 16:35:12 -0500 Received: from quinthar.com ([72.52.120.178]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4k5m-00087Y-Mw for p2psip@ietf.org; Tue, 18 Dec 2007 16:35:12 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Tue, 18 Dec 2007 13:35:08 -0800 From: "David Barrett" To: "'Ali Fessi'" Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Tue, 18 Dec 2007 13:35:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <476837F7.8030608@uni-tuebingen.de> Thread-Index: AchBuv8eTulYAi21R7WJrtw0bL2YcAAAhjoQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: And if I check the "save my password" checkbox that every client will naturally provide? Then my identity is lost forever? One mitigation would be to make the certificates very short-lived: say, daily. Then if I lose my laptop, then a hacker can impersonate me for the rest of the day. (Though if AT&T took 24 hours to turn off your cell phone I'm not sure people would be satisfied by that.) However, then that means we need to re-enroll daily, and it's not really an "enrollment" server but rather a "reserve your name on the system for a day" server. To which we might add some sort of long-lived credentials on the enrollment server so -- if I forget to log on one day -- somebody can't hijack my name. Then it becomes a full-fledged authenticate/authorize/enroll server that we need to check daily. Regardless, it still sounds an awful lot like a central authentication server that needs to be consulted at the start of each session (and periodically thereafter) to get onto the network. I don't think this is bad. I just think it's unavoidable. -david > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] > Sent: Tuesday, December 18, 2007 1:13 PM > To: David Barrett > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Re: HIP pros and cons > > Hi David, > > David Barrett wrote: > > Just curious, if my laptop gets stolen, will P2PSIP provide any facility > for > > me to prevent the thief from making and receiving calls in my name? > > Once you have a certificate that you have received from the enrollment > server, you can protect the private key that belongs to the certificate > with a password on your local machine. > > So nobody will be able to steal your identity (well, except with a > dictionary attack on your password). > > You don't need to contact one of the login servers here, except for > verifying whether a peer certificate is in the revocation list. > Certificate revocation is indeed a problem. > > > Cheers, > Ali > > > If so, how will that be done without a 24/7 realtime check to either a > > centralized or federated server? > > If we assume there's some kind of password, then that means there's some > > sort of password check. If we assume we can ban clients, then we need > to > > somehow record which clients are banned and check that. If we can > revoke > > certificates, then there's a certificate revocation list. > > > > Is there any way to support this seemingly obvious requirement -- the > > requirement that I can prevent a thief from forever, undetectably > > impersonating me -- without some sort of central, realtime, 24/7 lookup? > > > > Or is the answer "to be determined" or "not our problem; we punt this to > > another layer"? > > > > -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 19 14:32:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54eP-0006eD-Tq; Wed, 19 Dec 2007 14:32:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54eN-0006ad-JH for p2psip@ietf.org; Wed, 19 Dec 2007 14:32:16 -0500 Received: from ebru.winwebhosting.com ([74.54.111.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J54eM-0002xN-Vk for p2psip@ietf.org; Wed, 19 Dec 2007 14:32:15 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1J54eB-0001o9-PY; Wed, 19 Dec 2007 13:32:04 -0600 From: "Brian Rosen" To: "'David Barrett'" , "'Ali Fessi'" References: <476837F7.8030608@uni-tuebingen.de> Subject: RE: [P2PSIP] Re: HIP pros and cons Date: Wed, 19 Dec 2007 14:32:07 -0500 Message-ID: <05c101c84275$d940d250$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchBuv8eTulYAi21R7WJrtw0bL2YcAAAhjoQAC4ShiA= In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Perhaps we store the CRL in the DHT. The problem you want to protect against is amenable to a non-real time CRL update mechanism, which is a solvable problem. If you wanted a near-instant revocation, then you need a real time access to an up to date CRL. Brian > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Tuesday, December 18, 2007 4:35 PM > To: 'Ali Fessi' > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] Re: HIP pros and cons > > And if I check the "save my password" checkbox that every client will > naturally provide? Then my identity is lost forever? > > One mitigation would be to make the certificates very short-lived: say, > daily. Then if I lose my laptop, then a hacker can impersonate me for the > rest of the day. (Though if AT&T took 24 hours to turn off your cell > phone > I'm not sure people would be satisfied by that.) > > However, then that means we need to re-enroll daily, and it's not really > an > "enrollment" server but rather a "reserve your name on the system for a > day" > server. > > To which we might add some sort of long-lived credentials on the > enrollment > server so -- if I forget to log on one day -- somebody can't hijack my > name. > > Then it becomes a full-fledged authenticate/authorize/enroll server that > we > need to check daily. > > Regardless, it still sounds an awful lot like a central authentication > server that needs to be consulted at the start of each session (and > periodically thereafter) to get onto the network. > > I don't think this is bad. I just think it's unavoidable. > > -david > > > -----Original Message----- > > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] > > Sent: Tuesday, December 18, 2007 1:13 PM > > To: David Barrett > > Cc: p2psip@ietf.org > > Subject: Re: [P2PSIP] Re: HIP pros and cons > > > > Hi David, > > > > David Barrett wrote: > > > Just curious, if my laptop gets stolen, will P2PSIP provide any > facility > > for > > > me to prevent the thief from making and receiving calls in my name? > > > > Once you have a certificate that you have received from the enrollment > > server, you can protect the private key that belongs to the certificate > > with a password on your local machine. > > > > So nobody will be able to steal your identity (well, except with a > > dictionary attack on your password). > > > > You don't need to contact one of the login servers here, except for > > verifying whether a peer certificate is in the revocation list. > > Certificate revocation is indeed a problem. > > > > > > Cheers, > > Ali > > > > > If so, how will that be done without a 24/7 realtime check to either a > > > centralized or federated server? > > > If we assume there's some kind of password, then that means there's > some > > > sort of password check. If we assume we can ban clients, then we need > > to > > > somehow record which clients are banned and check that. If we can > > revoke > > > certificates, then there's a certificate revocation list. > > > > > > Is there any way to support this seemingly obvious requirement -- the > > > requirement that I can prevent a thief from forever, undetectably > > > impersonating me -- without some sort of central, realtime, 24/7 > lookup? > > > > > > Or is the answer "to be determined" or "not our problem; we punt this > to > > > another layer"? > > > > > > -david > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 04:38:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eKO-00071Y-1r; Fri, 21 Dec 2007 04:38:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eKL-0006zv-UQ for p2psip@ietf.org; Fri, 21 Dec 2007 04:37:57 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5eKL-0003vg-Eq for p2psip@ietf.org; Fri, 21 Dec 2007 04:37:57 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8ED382EE8; Fri, 21 Dec 2007 11:37:56 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 52B012EBD; Fri, 21 Dec 2007 11:37:49 +0200 (EET) Date: Fri, 21 Dec 2007 11:37:49 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Ali Fessi Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: <476697F2.4080903@uni-tuebingen.de> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20d2bdfb0712121521x14e831cal2473fdf5045f4e37@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE40E@namail5.corp.adobe.com> <4765A9FF.7000903@uni-tuebingen.de> <24CCCC428EFEA2469BF046DB3C7A8D223AE414@namail5.corp.adobe.com> <476697F2.4080903@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Henry Sinnreich , Philip Matthews , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 17 Dec 2007, Ali Fessi wrote: Hi Ali, (I think there were already response to your message from Philip also) > For example, if you want to use a HIP overlay for P2PSIP lookup service, and > as soon as you find the Callee, you want to perform the subsequent SIP > signaling in a B2BUA mode and send your media streams directly using IP > routing. (although i know some people will say here you can use HIP. but i > think you don't want to use the HIP overlay for routing the media data) You can use HIP :) > In this case, you would use the HIP overlay for the lookup and will need to > use SRTP for protecting the media streams. and probably also TLS/DTLS for > protecting the B2B SIP signaling. > > I hope this was clear? Not exactly. > Another reason, is that there might a misunderstanding of the security > services provided by the HIP layer. e.g. some environments could use HIP for > the overlay and think they are safe, while HIP is configured to use null > encryption. So, this could lead to security holes quickly in practice. If the application needs to know this, it can query this using a getsockopt or similar call: http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt > In general, i think it is a good practice if the security of the application > does not depend on the security provided by the lower layers (under layer 4). Why? > BTW, the 3GPP IMS, for example, uses its own authentication and > confidentiality mechanisms independantly of the access network, which is, i > think, wise. What prevents the application from requesting a specific security service from the lower layers? > Also, if you look at things how they work today, you don't want to establish > a VPN tunnel to a web server if you want to protect your HTTP traffic. You > would rather use TLS. You are using VPN as a synonym for IPsec which is not entirely correct. VPN usually means that usually you have a gateway. In HIP there is usually no gateway (end-to-middle), but instead the traffic is end-to-end. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 04:38:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eKk-00021E-4C; Fri, 21 Dec 2007 04:38:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eKi-0001nQ-2F for p2psip@ietf.org; Fri, 21 Dec 2007 04:38:20 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5eKh-0003vy-Jq for p2psip@ietf.org; Fri, 21 Dec 2007 04:38:19 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 266452EE5; Fri, 21 Dec 2007 11:38:19 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 772D42ED8; Fri, 21 Dec 2007 11:38:12 +0200 (EET) Date: Fri, 21 Dec 2007 11:38:12 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Ali Fessi Subject: Re: [P2PSIP] HIP performance concerns (was HIP pros and cons) In-Reply-To: <4766A124.4080906@uni-tuebingen.de> Message-ID: References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> <4766A124.4080906@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mon, 17 Dec 2007, Ali Fessi wrote: > Hi all, > > some questions for the HIP experts among us: > > - HIP uses a Base Exchange (BEX) with 4 messages, and the BEX contains a > diffie hellman key exchange. (as you know, diffie hellman might cause some > performance problems on small devices) I gave already a reference to this list with measurement results with HIP on small devices. Did you read it? Also, I am having trouble in following your argumentation. First you say that TLS is more suitable than HIP, but TLS is also using Diffie-Hellman. HIP offers the performance TLS. In some cases, it might even offer better performance because HIP usually makes one key exchange between a pair of hosts, where as TLS can exchange may require one key exchange per transport layer session. > Do i need a HIP BEX each time before I can exchange any message with another > peer in the overlay? for example P2P routing messages? Yes if you want to secure the connection (and also to make it mobile). > as you know, P2P networks have generally the property that you need to > exchange messages frequently with other peers, for routing purposes, for DHT > maintenane, etc. So, it wouldn't be very efficient if i need to perform a HIP > BEX each time before I can exchange any other message, in particular under > high churn conditions. Security causes some extra overhead always. > - if you do mobility with HIP, you will need to update the IPSec SAs in the > kernel when a handover occurs. Is that correct? How well does this work? Has > there been some experiments that show that HIP can provide seamless mobility? > If yes, please provide a reference. I already provided references to this mailing list: http://www1.ietf.org/mail-archive/web/p2psip/current/msg03645.html -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 04:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eXA-0002my-Tf; Fri, 21 Dec 2007 04:51:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5eX9-0002ms-OJ for p2psip@ietf.org; Fri, 21 Dec 2007 04:51:11 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5eX8-0002gW-29 for p2psip@ietf.org; Fri, 21 Dec 2007 04:51:11 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5A96A2EE7; Fri, 21 Dec 2007 11:51:09 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 80DCD2EDD; Fri, 21 Dec 2007 11:51:02 +0200 (EET) Date: Fri, 21 Dec 2007 11:51:02 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: <200712181818.lBIIIWv9003612@romeo.rtfm.com> Message-ID: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> <20071217164438.38F0433C53@delta.rtfm.com> <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> <200712181818.lBIIIWv9003612@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Tue, 18 Dec 2007, Eric Rescorla wrote: Eric, > At Tue, 18 Dec 2007 19:45:49 +0200 (EET), > Miika Komu wrote: >> >> On Tue, 18 Dec 2007, Brian Rosen wrote: >> >> Hi Brian, >> >> thanks for the feedback. It seems like the alternative b is mandatory for >> p2p-sip. Otherwise, then I don't see how you are going to avoid the use of >> cryptographic certificates without compromising dht identifier security >> and revocation. >> >> In alternative b, it is still possible to use host generated dht key >> identifiers. > > Again, not if you want to use them as the locations in the DHT, > because then you get chosen location attacks. Yes but it costs. I don't see the difference here with host vs. enrollment server generated keys because the end-host can enroll several times until it is satisfied with the id. What makes the difference is the cost. Since I took the time to describe a detailed, step-by-step approach with host generated identifiers, could you do the same with enrollment server generated keys? Thanks. P.S. If you want to reference some work, please give the authors and titles to the publication or URL instead of some acronyms. Thanks. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 06:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5gQ4-0002vF-4O; Fri, 21 Dec 2007 06:52:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5gQ2-0002lP-P3 for p2psip@ietf.org; Fri, 21 Dec 2007 06:51:58 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5gQ2-0007eT-BH for p2psip@ietf.org; Fri, 21 Dec 2007 06:51:58 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 69AE520D57; Fri, 21 Dec 2007 12:51:57 +0100 (CET) X-AuditID: c1b4fb3c-ae794bb0000030cf-43-476ba8dd35c9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5048C20BE6; Fri, 21 Dec 2007 12:51:57 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 12:51:57 +0100 Received: from [159.107.2.106] ([159.107.2.106]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 12:51:55 +0100 Message-ID: <476BA8D9.4010203@ericsson.com> Date: Fri, 21 Dec 2007 13:51:53 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: P2PSIP Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2007 11:51:56.0377 (UTC) FILETIME=[E2DD5C90:01C843C7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Pekka Nikander Subject: [P2PSIP] New draft: HIP BONE X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, we have seen a lot of discussions on how HIP could relate to P2PSIP on this list lately. While this level of interest on HIP is a good thing (from the HIP community's perspective), there have been a few misconceptions and misunderstandings on what is essential to HIP (e.g., the ID/locator split) and what are just design or configuration choices made in a given HIP deployment (e.g., using self-certifying identifiers). With the draft below, we have tried to clarify a few of the design choices that can be made while defining the use of HIP in a given scenario (e.g., the use of a centralized enrollment server). In particular, we have focused on the use of HIP to build overlays. The draft also includes tutorial material on HIP so that readers who are not familiar with HIP can still follow what it is said in the draft. http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt The draft also discusses the relationship between HIP and P2PSIP. It clarifies that while HIP can be used to implement connection management, other functions such as overlay maintenance, and data storage and retrieval are implemented using a peer protocol such as RELOAD or P2PP. We thought that this clarification was important because it seems some people mistakingly thought HIP was a full-blown peer protocol proposal while, in reality, HIP only provides connection management. Enjoy your Christmas reading! ;o) Cheers, Gonzalo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 10:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kAI-0001ei-6i; Fri, 21 Dec 2007 10:51:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kAG-0001bC-0z for p2psip@ietf.org; Fri, 21 Dec 2007 10:51:56 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5kAF-0004TM-KV for p2psip@ietf.org; Fri, 21 Dec 2007 10:51:55 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 95E505081A; Fri, 21 Dec 2007 07:51:32 -0800 (PST) Date: Fri, 21 Dec 2007 07:51:32 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] HIP performance concerns (was HIP pros and cons) In-Reply-To: References: <001201c83fd6$58430e80$da07740a@dellwei> <24CCCC428EFEA2469BF046DB3C7A8D223AE412@namail5.corp.adobe.com> <000001c84058$fabe14c0$da07740a@dellwei> <4766A124.4080906@uni-tuebingen.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071221155132.95E505081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Fri, 21 Dec 2007 11:38:12 +0200 (EET), Miika Komu wrote: > > On Mon, 17 Dec 2007, Ali Fessi wrote: > > > Hi all, > > > > some questions for the HIP experts among us: > > > > - HIP uses a Base Exchange (BEX) with 4 messages, and the BEX contains a > > diffie hellman key exchange. (as you know, diffie hellman might cause some > > performance problems on small devices) > > I gave already a reference to this list with measurement results with HIP > on small devices. Did you read it? > > Also, I am having trouble in following your argumentation. First you say > that TLS is more suitable than HIP, but TLS is also using Diffie-Hellman. Actually, TLS is sometimes Diffie-Hellman. There are pure RSA modes, as well as ECDH modes. > HIP offers the performance TLS. In some cases, it might even offer better > performance because HIP usually makes one key exchange between a pair of > hosts, where as TLS can exchange may require one key exchange per > transport layer session. Only if you don't implement session caching, but why wouldn't you do that? -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 11:23:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kfC-00083d-Ee; Fri, 21 Dec 2007 11:23:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kfB-00083Y-6z for p2psip@ietf.org; Fri, 21 Dec 2007 11:23:53 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5kfA-0002xp-HZ for p2psip@ietf.org; Fri, 21 Dec 2007 11:23:53 -0500 Received: by wx-out-0506.google.com with SMTP id s8so201887wxc.31 for ; Fri, 21 Dec 2007 08:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=hlL/SdfU9WxJpR5cxMK8pOuwlg1W1XPwol8f+5Inb3Q=; b=gTI4Q2/WxpTQlG55mi+arl0TnYMfXvGK1ms2rS2HmvanYUGxSNqoIl+cFZrzzXSXTL3wGDmsnNmSzmxd639towcqqDTr5JQaDo+35+yRO3lZNauq88ctQIU8bgFMdv05TfCJ0R0RXnBYqAB3cKyXriMlpvAi853Y7ZqhorH5lO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=BcSvWxozLuJUvwGAEbhpDKZHl6b+dqP3cE/SAMTxOOqKjiwVc3wTURBA9O7xa6fU6SaDZ8XjZvKDtJO7M5dSPXdUu0XomxOvjYtj1PRs9j9CpyqPonBqs2uux/teJGZTaZ2LKjAsmb1ghcZiXUKXOyfgGr4bfx3uKyZxt4ynOcE= Received: by 10.142.194.1 with SMTP id r1mr713831wff.176.1198254230556; Fri, 21 Dec 2007 08:23:50 -0800 (PST) Received: by 10.142.52.2 with HTTP; Fri, 21 Dec 2007 08:23:50 -0800 (PST) Message-ID: <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> Date: Fri, 21 Dec 2007 11:23:50 -0500 From: "Bruce Lowekamp" To: "Gonzalo Camarillo" Subject: Re: [P2PSIP] New draft: HIP BONE In-Reply-To: <476BA8D9.4010203@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <476BA8D9.4010203@ericsson.com> X-Google-Sender-Auth: ca90b1b667061bff X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Gonzalo, Many thanks to you, Pekka, and Jani for putting in yet more effort to try to clarify a possible role for HIP in P2PSIP. At a high level, in section 5 you list two potential outcomes, which are for the wg to settle on HIP for all connection management or for the wg to not use hip, but retain modularity that allows it. I would rather see option 2 reworded along the lines of "the wg will develop a protocol that uses HIP as one possible choice for its connection management layer. The HIP module will not be mandatory to implement, but its specification will be developed by the wg." I think that's something along the lines of what you're thinking. It's certainly what I'm hoping the outcome will be. I am sure there are other options as well (ignore hip, try to maintain compatibility but don't specify, etc). On a specific issue, I'm still a little confused about where the line is between what the overlay does with overlay routing and what HIP-BONE should be responsible for. Your section 3.2 proposes that I1 packets are sent across the Peer Protocol overlay. Were I to implement RELOAD on top of HIP-BONE, what exactly does this mean? Does this mean that I send a RELOAD CONNECT message and the contents of that message are now an I1 instead of ICE candidates? Or would RELOAD's CONNECT go away and RELOAD would simply try to send a message directly to a new PeerID via its ORCHID and the HIP-BONE layer would then produce an upcall to RELOAD asking that an I1 be tunneled across the overlay? Similarly, in section 3.3, you suggest that a HIP message could be tunneled through the overlay rather than establishing a new connection for a simple query. Generally, dht maintenance operations and resource query operations are somewhat distinct. If I'm using recursive routing, a resource query operation would never cause a new connection to be formed, but instead the query would be routed across the overlay by the Peer Protocol. Assuming I'm understanding your layering correctly, that would be implemented by the Peer Protocol knowing the translation between the PeerID of the next hop that it has a connection to and that peer's ORCHID (or LSI) and the Peer Protocol would route the query message to that next hop just like it has a direct IP connection (and generally be unaware of the difference). So I'm unclear on when the mechanism in 3.3 would be invoked. If I'm using recursive routing, the only time I would send a message to a new peer for which I do not have an existing connection would be: - during dht maintenance if I decide I should have a connection with this new peer - if the application decides it wants to send an application-layer message directly RELOAD proposes to solve the first case using CONNECT messages, as discussed above. It also proposes to solve the second case with a CONNECT message (or TUNNEL, as decided by the application). This is I think where HIP (or at least id/loc) has its biggest potential win. Is the use of a new ORCHID by the application the proposed application of section 3.3? If so, how would the decision be made of when to tunnel and when to open a new direct connection? Bruce On Dec 21, 2007 6:51 AM, Gonzalo Camarillo wrote: > Hi, > > we have seen a lot of discussions on how HIP could relate to P2PSIP on > this list lately. While this level of interest on HIP is a good thing > (from the HIP community's perspective), there have been a few > misconceptions and misunderstandings on what is essential to HIP (e.g., > the ID/locator split) and what are just design or configuration choices > made in a given HIP deployment (e.g., using self-certifying identifiers). > > With the draft below, we have tried to clarify a few of the design > choices that can be made while defining the use of HIP in a given > scenario (e.g., the use of a centralized enrollment server). In > particular, we have focused on the use of HIP to build overlays. The > draft also includes tutorial material on HIP so that readers who are not > familiar with HIP can still follow what it is said in the draft. > > http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt > > The draft also discusses the relationship between HIP and P2PSIP. It > clarifies that while HIP can be used to implement connection management, > other functions such as overlay maintenance, and data storage and > retrieval are implemented using a peer protocol such as RELOAD or P2PP. > We thought that this clarification was important because it seems some > people mistakingly thought HIP was a full-blown peer protocol proposal > while, in reality, HIP only provides connection management. > > Enjoy your Christmas reading! ;o) > > Cheers, > > Gonzalo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 12:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lL0-0003Tp-8j; Fri, 21 Dec 2007 12:07:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lKy-0003Hi-Ss for p2psip@ietf.org; Fri, 21 Dec 2007 12:07:04 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5lKy-0003nN-EH for p2psip@ietf.org; Fri, 21 Dec 2007 12:07:04 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6A1C35081A; Fri, 21 Dec 2007 09:06:41 -0800 (PST) Date: Fri, 21 Dec 2007 09:06:40 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] Re: HIP pros and cons In-Reply-To: References: <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <20071212160813.3863033C6D@delta.rtfm.com> <20071213163033.6EE1433C72@delta.rtfm.com> <20071213205251.548E933C6D@delta.rtfm.com> <20071214145748.E37DF33C6D@delta.rtfm.com> <20071217164438.38F0433C53@delta.rtfm.com> <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> <200712181818.lBIIIWv9003612@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071221170641.6A1C35081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Fri, 21 Dec 2007 11:51:02 +0200 (EET), Miika Komu wrote: > > On Tue, 18 Dec 2007, Eric Rescorla wrote: > > Eric, > > > At Tue, 18 Dec 2007 19:45:49 +0200 (EET), > > Miika Komu wrote: > >> > >> On Tue, 18 Dec 2007, Brian Rosen wrote: > >> > >> Hi Brian, > >> > >> thanks for the feedback. It seems like the alternative b is mandatory for > >> p2p-sip. Otherwise, then I don't see how you are going to avoid the use of > >> cryptographic certificates without compromising dht identifier security > >> and revocation. > >> > >> In alternative b, it is still possible to use host generated dht key > >> identifiers. > > > > Again, not if you want to use them as the locations in the DHT, > > because then you get chosen location attacks. > > Yes but it costs. I don't see the difference here with host vs. enrollment > server generated keys because the end-host can enroll several times until > it is satisfied with the id. What makes the difference is the cost. For the nth time, yes, but it requires a separate query to the enrollment server, which the enrollment server can throttle. This doesn't work if the enrollment server lets the peer propose the peer-id, since the peer can mount an offline attack on the location. Again, this is all in my slides from YVR. > Since I took the time to describe a detailed, step-by-step approach with > host generated identifiers, could you do the same with enrollment > server generated keys? Thanks. I don't propose using enrollment server generated keys. I propose separating cryptographic keys from peer-ids and using certificates to bind them together. This is described in fairly complete detail draft-bryan-p2psip-reload-02. > P.S. If you want to reference some work, please give the authors and > titles to the publication or URL instead of some acronyms. Thanks. I generally try to. If there's a particular one that wasn't clear lemme know and I'll send you a full reference. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 13:18:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5mS3-0003qi-Kf; Fri, 21 Dec 2007 13:18:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5mS2-0003qd-BD for p2psip@ietf.org; Fri, 21 Dec 2007 13:18:26 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5mS1-0000lC-To for p2psip@ietf.org; Fri, 21 Dec 2007 13:18:26 -0500 Received: from irtcluster02.cs.columbia.edu (irtcluster02.cs.columbia.edu [128.59.19.154]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lBLIIIGY029929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Dec 2007 13:18:19 -0500 (EST) Date: Fri, 21 Dec 2007 13:18:18 -0500 (EST) From: Salman Abdul Baset To: Gonzalo Camarillo Subject: Re: [P2PSIP] New draft: HIP BONE In-Reply-To: <476BA8D9.4010203@ericsson.com> Message-ID: References: <476BA8D9.4010203@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org My general concern with running a peer protocol (RELOAD or P2PP) on top of HIP is that one will need to understand somewhat two completely different documents (HIP and peer protocol document) to implement a working solution. That increases the bar for someone who will like to quickly design and develop a working p2p solution. I think there is a need to carefully perform message overhead analysis of HIP under different levels of churn. I am a bit confused about splitting the functionality between the overlay layer and the HIP layer. Is peer protocol no more than an encoding mechanism when implemented on top of HIP? -salman On Fri, 21 Dec 2007, Gonzalo Camarillo wrote: > Hi, > > we have seen a lot of discussions on how HIP could relate to P2PSIP on this > list lately. While this level of interest on HIP is a good thing (from the > HIP community's perspective), there have been a few misconceptions and > misunderstandings on what is essential to HIP (e.g., the ID/locator split) > and what are just design or configuration choices made in a given HIP > deployment (e.g., using self-certifying identifiers). > > With the draft below, we have tried to clarify a few of the design choices > that can be made while defining the use of HIP in a given scenario (e.g., the > use of a centralized enrollment server). In particular, we have focused on > the use of HIP to build overlays. The draft also includes tutorial material > on HIP so that readers who are not familiar with HIP can still follow what it > is said in the draft. > > http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt > > The draft also discusses the relationship between HIP and P2PSIP. It > clarifies that while HIP can be used to implement connection management, > other functions such as overlay maintenance, and data storage and retrieval > are implemented using a peer protocol such as RELOAD or P2PP. We thought that > this clarification was important because it seems some people mistakingly > thought HIP was a full-blown peer protocol proposal while, in reality, HIP > only provides connection management. > > Enjoy your Christmas reading! ;o) > > Cheers, > > Gonzalo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 15:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5oIB-0000S1-2b; Fri, 21 Dec 2007 15:16:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5oI9-0000Rw-Qf for p2psip@ietf.org; Fri, 21 Dec 2007 15:16:21 -0500 Received: from n2.nomadiclab.com ([2001:14b8:400:101::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5oI9-0000Ds-3E for p2psip@ietf.org; Fri, 21 Dec 2007 15:16:21 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 174201F7EA6; Fri, 21 Dec 2007 22:16:20 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 765B51EF41B; Fri, 21 Dec 2007 22:16:19 +0200 (EET) In-Reply-To: <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [P2PSIP] New draft: HIP BONE Date: Fri, 21 Dec 2007 22:16:18 +0200 To: Bruce Lowekamp X-Mailer: Apple Mail (2.753) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Bruce, Let me try to clarify a few of your HIP-specific questions. In general, we tried to clarify the proposed relationship between HIP and the peer protocols by the architectural analogy (in Section 6), where we state that HIP acts in a role similar to IP (forwarding that results in connectivity) and the peer protocols in a role similar to routing protocols such as OSPF, i.e., building the routing tables needed to do forwarding. > On a specific issue, I'm still a little confused about where the line > is between what the overlay does with overlay routing and what > HIP-BONE should be responsible for. Your section 3.2 proposes that I1 > packets are sent across the Peer Protocol overlay. Well, not quite. We propose that "Nodes in the overlay forward I1 packets in a hop-by-hop fashion according to the overlay's routing table towards its destination." While that is true, it is inaccurate in the sense that it does not make the distinction between the routing tables (as build by the peer protocols) and the forwarding tables (as used by HIP) clear enough. A better way to state what we propose might be "Nodes participating into an overlay forward I1 packets in a hop-by-hop fashion over the HIP BONE using the forwarding tables, which in turn are built based on the routing table constructed by the peer protocol for the overlay." But that would be quite a bunch to engulf at one time. > Were I to > implement RELOAD on top of HIP-BONE, what exactly does this mean? [Caveat: I don't know RELOAD nor other peer protocols in detail.] > Does this mean that I send a RELOAD CONNECT message and the contents > of that message are now an I1 instead of ICE candidates? Or would > RELOAD's CONNECT go away and RELOAD would simply try to send a message > directly to a new PeerID via its ORCHID and the HIP-BONE layer would > then produce an upcall to RELOAD asking that an I1 be tunneled across > the overlay? I cannot say anything about RELOAD's CONNECT, but my understanding is that a forwarding node would look at the next hop ORCHID based on the forwarding table, and then pass the packet to the HIP implementation. The HIP implementation would then detect if there is an active HIP association towards that ORCHID. If there is, the I1 packet is passed over that HIP association. If there are not but there is a valid locator associated with the next hop ORCHID, then the I1 packet is passed over IP using the locator. If neither, there the forwarding table is faulty, and the HIP layer needs to kick the peer protocols to rebuild the forwarding table. That is similar to the case where the IP layer kicks the routing layer whenever it drops a packet due to missing route. An open question here is whether and how to report the error back, i.e., if there should be a function similar to ICMP. If yes, HIP NOTIFY packets could be used for that purpose. Further note that there are at least two choices of what to use as index to the forwarding table look up. Either one can use the Peer ID, presumably carried in a new HIP parameter in the I1 packet, or one can use the ORCHID, carried in the source HIT field in the I1 packet. From the high level point of view, both would work equally well, but as usual the devil may lie in the details. The latter would be structurally similar to the currently specified HIP rendezvous service, and has been used in previous suggestions for HIP- based overlays. > Similarly, in section 3.3, you suggest that a HIP message could be > tunneled through the overlay rather than establishing a new connection > for a simple query. My perhaps faulty understanding is that such "tunnelling" would be structurally similar to the case in 3.2. The only difference would be than in 3.2 we discussed forwarding I1 packets (and presumably the rest of the packets in the HIP base exchange), while in 3.3 we basically state that any HIP packets could be forwarded over the HIP BONE, similar to the I1s, without creating any new HIP association. In general, the proposed forwarding function is pretty similar to the IP overlay forward in Berkeley i3. > So I'm unclear on when the mechanism in 3.3 would be invoked. One situation where it would be needed is when the peers lose connectivity, e.g., due to both moving at the same time and no more knowing each other's locators. In HIP as defined today, the peers would use a HIP rendezvous server to pass HIP mobility update packets to pass the new locators. In the HIP BONE case, the idea is that the HIP rendezvous functionality is replaced by the HIP BONE, i.e., the overlay would be used to pass the mobility update packets. Other than that I cannot answer your question about 3.3., since I didn't understand that much about it. I am sorry, but I am really new to what is going on at P2PSIP. I hope that my answers above clarify our thinking. --Pekka Nikander _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 15:17:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5oJT-0001Qk-PK; Fri, 21 Dec 2007 15:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5oJS-0001GY-0v for p2psip@ietf.org; Fri, 21 Dec 2007 15:17:42 -0500 Received: from n2.nomadiclab.com ([2001:14b8:400:101::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5oJR-0000F5-PN for p2psip@ietf.org; Fri, 21 Dec 2007 15:17:42 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 28E941F7EA6; Fri, 21 Dec 2007 22:17:41 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id D83541EF41B; Fri, 21 Dec 2007 22:17:40 +0200 (EET) In-Reply-To: References: <476BA8D9.4010203@ericsson.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08593F92-804A-4483-B80C-10970C6AF81F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [P2PSIP] New draft: HIP BONE Date: Fri, 21 Dec 2007 22:17:39 +0200 To: Salman Abdul Baset X-Mailer: Apple Mail (2.753) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I am a bit confused about splitting the functionality between the > overlay layer and the HIP layer. Is peer protocol no more than an > encoding mechanism when implemented on top of HIP? At least to me it helped to try to understand the relationship as similar to the relationship between IP and routing protocols such as OSPF. Please see Section 6 of the draft, and my previous message to this list. --Pekka Nikander _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 17:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5q9N-0008Sr-5j; Fri, 21 Dec 2007 17:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5q9M-0008Sk-3u for p2psip@ietf.org; Fri, 21 Dec 2007 17:15:24 -0500 Received: from exprod6og102.obsmtp.com ([64.18.1.183] helo=psmtp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5q9L-0003JE-5z for p2psip@ietf.org; Fri, 21 Dec 2007 17:15:24 -0500 Received: from source ([192.150.20.142]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP; Fri, 21 Dec 2007 14:15:16 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBLMF2Gb016651; Fri, 21 Dec 2007 14:15:06 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBLMF0FV009820; Fri, 21 Dec 2007 14:15:01 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Dec 2007 07:14:59 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Dec 2007 14:14:53 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE466@namail5.corp.adobe.com> In-Reply-To: <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIP-P2P-SIP message flow examples Thread-Index: AchEDmGitFKEkdhQTL+eSyTaZRHD+QADlFkg References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> From: "Henry Sinnreich" To: "Pekka Nikander" , "Bruce Lowekamp" X-OriginalArrivalTime: 21 Dec 2007 22:14:59.0156 (UTC) FILETIME=[ECBCC140:01C8441E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: P2PSIP Mailing List Subject: [P2PSIP] HIP-P2P-SIP message flow examples X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org (I have changed the Subject name) > I am sorry, but I am really =20 > new to what is going on at P2PSIP. Welcome to the crowd!=20 Many of us are just as new to what is going on in HIP. At this point time it seems we must bridge some interdisciplinary divides alluded to in these postings. Someone or a group that understands all three: HIP, DHT and SIP would be very helpful with some message flows (call flows in SIP parlance).=20 Using the example message flows, the debated points on the merits of HIP and also possible duplication with TLS, DTL and SRTP could be illustrated. Pushing the envelope; the associated protocol layer diagrams would also help. Diagrams and message flows are worth 1,000s of email words :-) I am embarrassed to admit not knowing enough to volunteer to contribute. Henry -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 Sent: Friday, December 21, 2007 12:16 PM To: Bruce Lowekamp Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] New draft: HIP BONE Hi Bruce, Let me try to clarify a few of your HIP-specific questions. In =20 general, we tried to clarify the proposed relationship between HIP =20 and the peer protocols by the architectural analogy (in Section 6), =20 where we state that HIP acts in a role similar to IP (forwarding that =20 results in connectivity) and the peer protocols in a role similar to =20 routing protocols such as OSPF, i.e., building the routing tables =20 needed to do forwarding. > On a specific issue, I'm still a little confused about where the line > is between what the overlay does with overlay routing and what > HIP-BONE should be responsible for. Your section 3.2 proposes that I1 > packets are sent across the Peer Protocol overlay. Well, not quite. We propose that "Nodes in the overlay forward I1 =20 packets in a hop-by-hop fashion according to the overlay's routing =20 table towards its destination." While that is true, it is inaccurate =20 in the sense that it does not make the distinction between the =20 routing tables (as build by the peer protocols) and the forwarding =20 tables (as used by HIP) clear enough. A better way to state what we propose might be "Nodes participating =20 into an overlay forward I1 packets in a hop-by-hop fashion over the =20 HIP BONE using the forwarding tables, which in turn are built based =20 on the routing table constructed by the peer protocol for the =20 overlay." But that would be quite a bunch to engulf at one time. > Were I to > implement RELOAD on top of HIP-BONE, what exactly does this mean? [Caveat: I don't know RELOAD nor other peer protocols in detail.] > Does this mean that I send a RELOAD CONNECT message and the contents > of that message are now an I1 instead of ICE candidates? Or would > RELOAD's CONNECT go away and RELOAD would simply try to send a message > directly to a new PeerID via its ORCHID and the HIP-BONE layer would > then produce an upcall to RELOAD asking that an I1 be tunneled across > the overlay? I cannot say anything about RELOAD's CONNECT, but my understanding is =20 that a forwarding node would look at the next hop ORCHID based on the =20 forwarding table, and then pass the packet to the HIP =20 implementation. The HIP implementation would then detect if there is =20 an active HIP association towards that ORCHID. If there is, the I1 =20 packet is passed over that HIP association. If there are not but =20 there is a valid locator associated with the next hop ORCHID, then =20 the I1 packet is passed over IP using the locator. If neither, there =20 the forwarding table is faulty, and the HIP layer needs to kick the =20 peer protocols to rebuild the forwarding table. That is similar to =20 the case where the IP layer kicks the routing layer whenever it drops =20 a packet due to missing route. An open question here is whether and =20 how to report the error back, i.e., if there should be a function =20 similar to ICMP. If yes, HIP NOTIFY packets could be used for that =20 purpose. Further note that there are at least two choices of what to use as =20 index to the forwarding table look up. Either one can use the Peer =20 ID, presumably carried in a new HIP parameter in the I1 packet, or =20 one can use the ORCHID, carried in the source HIT field in the I1 =20 packet. From the high level point of view, both would work equally =20 well, but as usual the devil may lie in the details. The latter =20 would be structurally similar to the currently specified HIP =20 rendezvous service, and has been used in previous suggestions for HIP-=20 based overlays. > Similarly, in section 3.3, you suggest that a HIP message could be > tunneled through the overlay rather than establishing a new connection > for a simple query. My perhaps faulty understanding is that such "tunnelling" would be =20 structurally similar to the case in 3.2. The only difference would =20 be than in 3.2 we discussed forwarding I1 packets (and presumably the =20 rest of the packets in the HIP base exchange), while in 3.3 we =20 basically state that any HIP packets could be forwarded over the HIP =20 BONE, similar to the I1s, without creating any new HIP association. =20 In general, the proposed forwarding function is pretty similar to the =20 IP overlay forward in Berkeley i3. > So I'm unclear on when the mechanism in 3.3 would be invoked. One situation where it would be needed is when the peers lose =20 connectivity, e.g., due to both moving at the same time and no more =20 knowing each other's locators. In HIP as defined today, the peers =20 would use a HIP rendezvous server to pass HIP mobility update packets =20 to pass the new locators. In the HIP BONE case, the idea is that the =20 HIP rendezvous functionality is replaced by the HIP BONE, i.e., the =20 overlay would be used to pass the mobility update packets. Other than that I cannot answer your question about 3.3., since I =20 didn't understand that much about it. I am sorry, but I am really =20 new to what is going on at P2PSIP. I hope that my answers above clarify our thinking. --Pekka Nikander _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 21 17:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qG8-0000PK-JW; Fri, 21 Dec 2007 17:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qG6-0000N5-Pm; Fri, 21 Dec 2007 17:22:22 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5qG5-0003S0-K4; Fri, 21 Dec 2007 17:22:22 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBLMMKnR018378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Dec 2007 14:22:20 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBLMMKER023919; Fri, 21 Dec 2007 14:22:20 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBLMMG8J023792; Fri, 21 Dec 2007 14:22:19 -0800 (PST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 14:22:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8441F.F313CEC2" Date: Fri, 21 Dec 2007 14:22:16 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D070BA682@XCH-NW-2V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Boeing HIP Implementation of SIP (which is point-to-point secure SIP) Thread-Index: AchEH96vkLdr2CwpRny3bB+oZLdYwQ== From: "Paine, Richard H" To: , X-OriginalArrivalTime: 21 Dec 2007 22:22:19.0528 (UTC) FILETIME=[F3383080:01C8441F] X-Spam-Score: -4.0 (----) X-Scan-Signature: ee55aaecc4f51e26a5b012c189b5823d Cc: Subject: [P2PSIP] Boeing HIP Implementation of SIP (which is point-to-point secure SIP) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8441F.F313CEC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Vancouver meeting, there was a joint meeting of the HIP and P2PSIP groups on Friday morning. At this meeting, Boeing committed to sent the P2PSIP group a releasable white paper on the Boeing HIP implementation that is, in effect, point-to-point secure SIP. =20 <>=20 The next step beyond this is to hold a teleconference in the first or second week of the new year to discuss this paper. Please note that although the identity in this example is an IPv6 address, any cryptographic identity can be used as a name in the HIP namespace. The Boeing intent is to use PKI crytographic identities in the HIP namespace. Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 ------_=_NextPart_001_01C8441F.F313CEC2 Content-Type: application/msword; name="NGI_SMA_Boeing_VoWLAN_Demo_White_Paper_12-8-07.doc" Content-Transfer-Encoding: base64 Content-Description: NGI_SMA_Boeing_VoWLAN_Demo_White_Paper_12-8-07.doc Content-Disposition: attachment; filename="NGI_SMA_Boeing_VoWLAN_Demo_White_Paper_12-8-07.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA2wAAAAAAAAAA EAAA2QAAAAEAAAD+////AAAAANUAAADcAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAI2AJBAAA+BK/AAAAAAAAEAAAAAAABgAAxhwAAA4AYmpiaqEVoRUAAAAAAAAAAAAAAAAAAAAA AAAJBBYAtV4BAMN/AADDfwAAxhQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAABIEAAAAAAAAEgQAABIE AAAAAAAAEgQAAAAAAAASBAAAAAAAABIEAAAAAAAAEgQAABQAAAAAAAAAAAAAACYEAAAAAAAAjgoA AAAAAACOCgAAAAAAAI4KAAAAAAAAjgoAABQAAACiCgAAFAAAACYEAAAAAAAAsRQAABQBAADCCgAA TAAAAA4LAAAAAAAADgsAAAAAAAAOCwAAAAAAAA4LAAAAAAAAiQ0AAAAAAACJDQAAAAAAAIkNAAAA AAAAMBQAAAIAAAAyFAAAAAAAADIUAAAAAAAAMhQAAAAAAAAyFAAAAAAAADIUAAAAAAAAMhQAACQA AADFFQAAaAIAAC0YAADGAAAAVhQAABUAAAAAAAAAAAAAAAAAAAAAAAAAEgQAAAAAAACpDwAAAAAA AAAAAAAAAAAAAAAAAAAAAABJDQAAQAAAAIkNAAAAAAAAqQ8AAAAAAACpDwAAAAAAAFYUAAAAAAAA AAAAAAAAAAASBAAAAAAAABIEAAAAAAAADgsAAAAAAAAAAAAAAAAAAA4LAAA7AgAAaxQAABYAAAD9 EAAAAAAAAP0QAAAAAAAA/RAAAAAAAACpDwAA7gAAABIEAAAAAAAADgsAAAAAAAASBAAAAAAAAA4L AAAAAAAAMBQAAAAAAAAAAAAAAAAAAP0QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAqQ8AAAAAAAAwFAAAAAAAAAAAAAAAAAAA/RAAAAAAAAD9EAAA HgAAAHgTAAAYAAAAEgQAAAAAAAASBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBMAAAAAAAAOCwAAAAAAALYKAAAMAAAAgAxXXR9E yAEAAAAAAAAAAI4KAAAAAAAAlxAAACIAAACQEwAACAAAAAAAAAAAAAAAMBQAAAAAAACBFAAAMAAA ALEUAAAAAAAAmBMAACwAAADzGAAAAAAAALkQAAAuAAAA8xgAABAAAADEEwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPMYAAAAAAAAAAAAAAAAAAASBAAAAAAAAMQTAABsAAAAiQ0AAGgAAADxDQAASgAAAP0Q AAAAAAAAOw4AADwAAAB3DgAAMgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiQ0A AAAAAACJDQAAAAAAAIkNAAAAAAAAVhQAAAAAAABWFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA5xAAABYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIkNAAAA AAAAiQ0AAAAAAACJDQAAAAAAALEUAAAAAAAAqQ8AAAAAAACpDwAAAAAAAKkPAAAAAAAAqQ8AAAAA AAAAAAAAAAAAACYEAAAAAAAAJgQAAAAAAAAmBAAApAQAAMoIAADEAQAAJgQAAAAAAAAmBAAAAAAA ACYEAAAAAAAAyggAAAAAAAAmBAAAAAAAACYEAAAAAAAAJgQAAAAAAAASBAAAAAAAABIEAAAAAAAA EgQAAAAAAAASBAAAAAAAABIEAAAAAAAAEgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJvZWlu ZyBWb1dMQU4gSW1wbGVtZW50YXRpb24gYW5kIERlbW9uc3RyYXRpb24NT3JsaWUgVC4gQnJld2Vy IChvcmxpZS50LmJyZXdlckBib2VpbmcuY29tKQ1EYXZpZCBNYXR0ZXMgKGRhdmlkLm1hdHRlc0Bi b2VpbmcuY29tKQ1SaWNoYXJkIEguIFBhaW5lIChyaWNoYXJkLmgucGFpbmVAYm9laW5nLmNvbSkN U3RldmVuIEMuIFZlbmVtYSAoEyBIWVBFUkxJTksgIm1haWx0bzpzdGV2ZW4uYy52ZW5lbWFAYm9l aW5nLmNvbSIgARRzdGV2ZW4uYy52ZW5lbWFAYm9laW5nLmNvbRUpDQ0xMi84LzA3DQ1UaGlzIGlz IGEgdGVjaG5pY2FsIGRlc2NyaXB0aW9uIG9mIHRoZSBCb2Vpbmcgc2VjdXJlIFZvaWNlIG92ZXIg V2lyZWxlc3MgTG9jYWwgQXJlYSBOZXR3b3JrIChWb1dMQU4pIGRlbW9uc3RyYXRpb24gaW5jb3Jw b3JhdGluZyB0aGUgSUVURpJzIEhvc3QgSWRlbnRpdHkgUHJvdG9jb2wgKEhJUCkuICBUaGUgcmVx dWlyZW1lbnQgaXMgdG8gc2VjdXJlIHRoZSBmYWN0b3J5IHByb2R1Y3Rpb24tY3JpdGljYWwgY29t bXVuaWNhdGlvbnMgc3lzdGVtcywgaW5jbHVkaW5nIHZvaWNlLiAgVGhlIGRldmVsb3BtZW50IG9m IGEgVm9XTEFOIGNhcGFiaWxpdHkgd2FzIGEgMjAwNyBwcm9qZWN0IGFuZCBjdWxtaW5hdGVkIGlu IGRlbW9uc3RyYXRpb24gb2YgdGhlIGNhcGFiaWxpdHkgaW4gRGVjZW1iZXIgMjAwNy4NDVRoZSBP cGVuIEdyb3VwknMgU2VjdXJlIE1vYmlsZSBBcmNoaXRlY3R1cmUgKFNNQSkgd2FzIHB1Ymxpc2hl ZCBpbiBGZWIgMjAwNCAoEyBIWVBFUkxJTksgImh0dHA6Ly93d3cub3Blbmdyb3VwLm9yZy9ib29r c3RvcmUvY2F0YWxvZy9lMDQxLmh0bSIgARRodHRwOi8vd3d3Lm9wZW5ncm91cC5vcmcvYm9va3N0 b3JlL2NhdGFsb2cvZTA0MS5odG0VKS4gIEEgQm9laW5nIGltcGxlbWVudGF0aW9uIG9mIFNNQSB3 YXMgZGVzaWduZWQgYW5kIGVuZ2luZWVyZWQgdG8gbWVldCB0aGUgbmVlZHMgb2YgdGhlIENvbW1l cmNpYWwgQWlycGxhbmUgZGl2aXNpb24gb2YgVGhlIEJvZWluZyBDb21wYW55LiAgVGhlIEJvZWlu ZyBpbXBsZW1lbnRhdGlvbiBpbmNsdWRlcyBzb21lIGluZnJhc3RydWN0dXJlIHBhcnRzIHRvIHN1 cHBvcnQgdGhlIHNlY3VyZSBhbmQgc2VhbWxlc3MgbW9iaWxpdHkgZmVhdHVyZXMgZGVzaXJlZCBi eSB0aGUgZW50ZXJwcmlzZS4gIFRoZSBpbXBsZW1lbnRhdGlvbiBpcyBwcmVzZW50bHkgaW4gcHJv ZHVjdGlvbiBvbiB0aGUgNzc3IGNyYXdsZXJzIHRoYXQgYXJlIHJvYm90cyB0aGF0IGNhcnJ5IGxh cmdlIHBvcnRpb25zIG9mIHRoZSA3NzcgYWlyY3JhZnQgd2hpbGUgaW4gcHJvZHVjdGlvbi4NDU9u ZSBvZiB0aGUgZnVuZGFtZW50YWwgY29uY2VwdHMgYmVoaW5kIHNlY3VyZSB2b2ljZSBpcyB0aGUg dXNlIG9mIHRoZSBIb3N0IElkZW50aXR5IFByb3RvY29sIChISVApLiAgSElQIHVzZXMgU2VjdXJp dHkgQXNzb2NpYXRpb25zIChTQSkgaW4gYSBuYW1lc3BhY2UgdG8gZXN0YWJsaXNoIHRoZSBlcXVp dmFsZW50IG9mIGEgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikgdGhhdCBwcm92aWRlcyBh IHByaXZhdGUgdHVubmVsIGJldHdlZW4gYW4gaW5pdGlhdG9yIGFuZCBhIHJlc3BvbmRlci4gIFRo ZSBmb2xsb3dpbmcgZ3JhcGhpY2FsIGRlc2NyaXB0aW9uIHNob3dzIHRoZSB1c2Ugb2YgYSBuYW1l c3BhY2UgdG8gY3JlYXRlIGFuIG92ZXJsYXkgbmV0d29yayB0aGF0IGFsbG93cyBzZWN1cmUgYW5k IG1vYmlsZSBjb21tdW5pY2F0aW9ucyBhY3Jvc3MgdGhlIG92ZXJsYXkgcGxhbmUuIA0NEyBTSEFQ RSAgXCogTUVSR0VGT1JNQVQgFAgBFQ0NVGhlIHR1bm5lbCBsb29rcyBqdXN0IGxpa2UgSVBTRUMs IGJ1dCBpbmNsdWRlcyBhIGNyeXB0b2dyYXBoaWMgaWRlbnRpdHkgaW4gdGhlIGhlYWRlciBvZiB0 aGUgcGFja2V0cyBiZWluZyBleGNoYW5nZWQgYmV0d2VlbiB0aGUgaW5pdGlhdG9yIGFuZCB0aGUg cmVzcG9uZGVyLiAgDQ1UaGUgU01BIGluZnJhc3RydWN0dXJlIGlzIGFuIGludGVncmFsIHBhcnQg b2YgdGhlIEJvZWluZyBJbnRyYW5ldCBhbmQgdGhlcmVmb3JlIHVzZXMgdGhlIFBLSSBhbmQgSW5m b3JtYXRpb24gVGVjaG5vbG9neSBzZXJ2aWNlcyBvZiB0aGUgSW50cmFuZXQuICBUaGVyZSBhcmUg dHdvIFNNQSBpbmZyYXN0cnVjdHVyZSBkZXBsb3ltZW50cywgb25lIGluIEJlbGxldnVlLCBXYXNo aW5ndG9uIGFuZCBvbmUgaW4gRXZlcmV0dCwgV2FzaGluZ3Rvbi4gIFRoZSBpbmZyYXN0cnVjdHVy ZSBkZXBsb3ltZW50cyBhbGwgb3BlcmF0ZSBpbiB0aGUgRE5TIG5hbWVzcGFjZSCTbW9iaWxlLnRs LmJvZWluZy5jb22ULiAgVGhpcyBuYW1lc3BhY2UgY29tcHJpc2VzIHRoZSBvdmVybGF5IG5ldHdv cmsgdGhhdCBpcyBzZWN1cmUgYW5kIG1vYmlsZS4NDVRoZSBmb2xsb3dpbmcgaXMgYSBkZXNjcmlw dGl2ZSBzbGlkZSBvbiB0aGUgQm9laW5nIFNNQSBpbmZyYXN0cnVjdHVyZSBuZWVkZWQgdG8gc3Vw cG9ydCB0aGUgVm9XTEFOIGNhcGFiaWxpdHk6DQ0TIFNIQVBFICBcKiBNRVJHRUZPUk1BVCAUCAEV DQ1UaGUgcmVkIGVuY2lyY2xlZCBkZXZpY2VzIGFyZSBOb2tpYSA3NzBzIGhhbmRoZWxkIGNvbXB1 dGVycyB0aGF0IGhhdmUgYSBVU0IgaGVhZHNldCBjYXBhYmlsaXR5IGFuZCBhcmUgdXNlZCB0byBk ZW1vbnN0cmF0ZSB0aGUgc2VjdXJlIGFuZCBtb2JpbGUgVm9XTEFOIGNhcGFiaWxpdHkuICBUaGUg Tm9raWEgNzcwcyBydW4gTGludXggYW5kIGEgU0lQIGltcGxlbWVudGF0aW9uIGNhbGxlZCBMaW5w aG9uZS4gIFRoZSBTSVAgc29mdHdhcmUgZG9lcyB0aGUgY2FsbCBzZXR1cCB3aGlsZSBISVAgcHJv dmlkZXMgdGhlIFNlY3VyaXR5IEFzc29jaWF0aW9uIGJhc2VkIG9uIHRoZSBpZGVudGl0eSBvZiB0 aGUgdXNlciBhbmQvb3IgZGV2aWNlLiAgVGhlIGZvbGxvd2luZyBpcyB0aGUgY2FsbCBzZXR1cDoN DVRoZSBOb2tpYSA3NzAgYW5kIGEgbGFwdG9wIGFyZSBpbiB0aGUgbW9iaWxlLnRsLmJvZWluZy5j b20gbmFtZXNwYWNlDVRoZSBOb2tpYSA3NzAgYW5kIHRoZSBsYXB0b3AgYXJlIGNvbm5lY3RlZCB0 byB0aGUgQm9laW5nIEludHJhbmV0IFdpcmVsZXNzIFByb3RlY3RlZCBBY2Nlc3MgKFdQQSkgV0xB TnMuDUhJUCBhbmQgTGlucGhvbmUgYXJlIG9uIHRoZSA3NzAgYW5kIHRoZSBsYXB0b3AuDUNhbGwg aW5pdGlhdGlvbiBhbmQgY2FsbCBzaWduYWxpbmcgaXMgdmlhIFNJUCB1c2luZyBMaW5waG9uZQ1F dGhlcmVhbCBpcyB1c2VkIHRvIHNob3cgdGhlIFJUUCBwYWNrZXRzIGVuY2Fwc3VsYXRlZCBhcyBF U1AgcGFja2V0cy4NDVRoZSBjYWxsIGluaXRpYXRpb24gaGFzIGFsc28gYmVlbiBzaG93biB0byB3 b3JrIHdpdGggYSBDaXNjbyBWT0lQIENhbGwgTWFuYWdlciB1c2luZyBTSVAgdG8gZG8gdGhlIGNh bGwgc2lnbmFsaW5nIHdpdGggdGhlIFJUUCBwYWNrZXRzIGVuY2Fwc3VsYXRlZCBhcyBFU1AgcGFj a2V0cyBleGNoYW5naW5nIHRoZSBzZWN1cmUgdm9pY2UgY29tbXVuaWNhdGlvbi4gIA0NV2hhdCBt aWdodCBiZSBsZXNzIHRoYW4gb2J2aW91cyBpbiB0aGUgQm9laW5nIGltcGxlbWVudGF0aW9uIGlz IHdoYXQgcGFydCB0aGUgU01BIGluZnJhc3RydWN0dXJlIHBhcnRzIHBsYXkgaW4gdGhpcyBWb1dM QU4gZGVtb25zdHJhdGlvbi4gIFRoZSBkaXJlY3RvcnkgcGxheXMgYW4gaW50ZWdyYWwgcm9sZSBp biBzdG9yaW5nIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaWRlbnRpdHkgKEhJVCksIHRoZSBJ UCBhZGRyZXNzLCBhbmQgdGhlIGxvY2F0aW9uIG9mIHRoZSBwZXJzb24gb3IgZGV2aWNlLiAgVGhl IG1vYmlsaXR5IGV2ZW50cyBhcmUgaGFuZGxlZCBieSBISVAgdXBkYXRlIHBhY2tldHMgYW5kIHRo ZXJlZm9yZSBjYW4gb2J0YWluIHRoZSBsYXRlc3QgSVAgYWRkcmVzcyBvZiB0aGUgZGV2aWNlIGFu ZCB0aGVyZWZvcmUgbW9iaWxpdHkgaXMgYmFzZWQgb24gdGhlIGxhdGVzdCBJUCBhZGRyZXNzIHJh dGhlciB0aGFuIGEgZml4ZWQgb3IgY2FyZS1vZiBhZGRyZXNzLiAgVGhlIEROUyBQcm94eSBlbmFi bGVzIGFueSByZXF1ZXN0IGZvciBhbiBJUCBhZGRyZXNzIHRvIGJlIGRpcmVjdGVkIHRvIHRoZSBk aXJlY3RvcnkgcmF0aGVyIHRoYW4gdGhlIGVudGVycHJpc2Ugb3IgdGhlIEludGVybmV0IEROUy4g IFRoZSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5IGVuYWJsZXMgYW4gYXV0aGVudGljYXRlZCBkZXZp Y2UgdG8gcmVxdWVzdCBhIHRlbXBvcmFyeSBjZXJ0aWZpY2F0ZSAoQm9laW5nIGNhbGxzIFRlbXBD ZXJ0cykgdG8gZ2l2ZSB0aGUgZGV2aWNlIGEgY2VydGlmaWNhdGUgaXQgY2FuIHN0b3JlIG9uIGl0 cyBmbGFzaCBtZW1vcnkgb3IgaGFyZCBkaXNrIGZvciByYXBpZCBhY2Nlc3MgaW4gdGhlIHNpZ25p bmcgb3IgdmVyaWZpY2F0aW9uIG9mIGNlcnRpZmljYXRlcy4gIFRoZSBtZXNzYWdlIGJyb2tlciBo YW5kbGVzIHJlYWwtdGltZSBsb2NhdGlvbiBldmVudHMgdGhyb3VnaCBhIEJvZWluZyBlbnRlcnBy aXNlIG1lc3NhZ2UgYnJva2VyIHNlcnZpY2UgKHVzaW5nIElCTZJzIE1RIFNlcmllcykuICANDUlu IHRoZSBiaWcgcGljdHVyZSwgdGhpcyBCb2VpbmcgaW1wbGVtZW50YXRpb24gZW5hYmxlcyBwYXJ0 aWNpcGFudHMgaW4gYW4gb3ZlcmxheSBuYW1lc3BhY2UgdG8gY29tbXVuaWNhdGUgc2VjdXJlbHkg YWNyb3NzIHRoZSBiaWcgSW50ZXJuZXQgdmlhIGRhdGEgb3Igdm9pY2UgYW55d2hlcmUgaW4gdGhl IHdvcmxkLiAgVGhpcyBWb1dMQU4gZGVtb25zdHJhdGlvbiBzaG93cyB3aGF0IGlzIGJlaW5nIGRv bmUgaW5zaWRlIGFuIGVudGVycHJpc2UgdG8gc2VjdXJlIHRoZSBpbmZyYXN0cnVjdHVyZS4gIEZv ciBvdXRzaWRlIHRoZSBlbnRlcnByaXNlLCBob3dldmVyLCBhIEhJUCBNaWRkbGVib3ggb24gdGhl IHBlcmltZXRlciBjYW4gc2VjdXJlIGVudGVycHJpc2UgY29tbXVuaWNhdGlvbnMgd29ybGR3aWRl IGZyb20gYW55IElQIGFkZHJlc3MsIGFueXdoZXJlIGluIHRoZSB3b3JsZC4gIEFzIGxvbmcgYXMg b25lIGhhcyBhIGdsb2JhbCBJUCBhZGRyZXNzLCB0aGUgQm9laW5nIFJBIGFuZCBUZW1wQ2VydCBw cm9jZXNzIGVuYWJsZXMgQm9laW5nIHBhcnRpY2lwYW50cyBpbiBhIEJvZWluZyBuYW1lc3BhY2Ug dG8gY29tbXVuaWNhdGUgc2VjdXJlbHkgd2l0aGluIHRoZWlyIG5hbWVzcGFjZSBvdmVybGF5LiAg VGhlIGVudGVycHJpc2UgdGhlbiBrbm93cyBleGFjdGx5IHdobyBpcyBjb21tdW5pY2F0aW5nIHdp dGggdGhlIGVudGVycHJpc2UgKGF1dGhlbnRpY2F0ZWQgYnkgdGhlIGVudGVycHJpc2UgUEtJKSBh bmQgZnJvbSB0aGUgbG9jYXRpb24gaW4gdGhlIGRpcmVjdG9yeSwga25vd3MgZXhhY3RseSB3aGVy ZSB0aGV5IGFyZS4NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAALggAAC8IAACSCAAA lQgAALAIAADCCAAAwwgAAPIIAADzCAAA9AgAAA4JAAAPCQAAEgkAAFAJAAB4CQAAfgkAAH8JAACN CQAAwwkAAC0KAACqCgAA+AoAAPkKAAD6CgAABgsAADkLAAA7CwAAPAsAAD0LAABwCwAAcQsAAKsM AAAgDQAAIQ0AACINAACIDQAAPw4AAOQOAADlDgAA5g4AAOcOAAD+DgAA/w4AAPPn49/j1MzUwcy0 zNSwrLCssKywrLCooKiZqI6ghaCorLCorIF9gX11gXUAAAAAAAAAAAAAAAAAAAAPA2oAAAAAFmjR Qr8AVQgBBhZoNkLWAAAGFmjRQr8AABAVaFIZEAAWaBc0lQAwShAAABUCCIEDagcBAAAGCAEWaBc0 lQBVCAEMFWgXNJUAFmgXNJUAAA8DagAAAAAWaBc0lQBVCAEGFmgXNJUAAAYWaBQVUAAABhZo/Trl AAAYFWhsBFkAFmh5N7QAMEoQAG1IBgRzSAYEABUCCIEDagAAAAAGCAEWaHk3tABVCAEPA2oAAAAA Fmh5N7QAVQgBFBVobARZABZoeTe0AG1IBgRzSAYEAAYWaPRtwAAABhZoeTe0AAAXFWh5N7QAFmgi BBsANQiBQ0ogAGFKIAAXFWh5N7QAFmj9OuUANQiBQ0ogAGFKIAAAKwAGAAAvCAAAWwgAAIIIAACw CAAAEQkAABIJAAAaCQAAGwkAAKsKAACsCgAAIQ0AACINAADlDgAA5g4AAAMPAAAEDwAApA8AAKUP AABEEQAARREAALQRAAC1EQAA0hEAANMRAABgEwAA9wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAA AADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA6gAA AAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAAN0AAAAAAAAA AAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAAAAAAAEAABnZPg+AwAABAAAZ2Q2QtYAAAcAAAMkAWEkAWdkbARZAAAEAABn ZP065QAABwAAAyQBYSQBZ2R5N7QAAAcAAAMkAWEkAWdk/TrlAAAZAAYAAMYcAAD+AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQH/DgAAAA8AAAEPAAACDwAAAw8A AAQPAACjDwAARREAALURAAC2EQAAzREAAM4RAADPEQAA0BEAANERAADSEQAA0xEAAPwRAAAPEgAA dhIAAJwSAABfEwAAYBMAAGETAAB7EwAAphMAAK8TAADCEwAAKxQAAD0UAAB7FAAAfBQAAMMUAACS FQAAkxUAAB8WAAC0FgAAuBYAAG0YAABzGAAAeBgAAHkYAACaGAAAmBkAAJkZAAAFGgAADhoAACYa AABQGgAA0RoAANoaAADFHAAAxhwAAPLq4tvX08/Tx8PHta3H16nDz8PPpc+loaWdoZ2hnaWdoZ2h maGZlZmVmZWhlZGNlZGNkZUAAAAAAAAAAAAAAAAAAAAAAAAGFmhzcrYAAAYWaPROlAAABhZoEDBZ AAAGFmhAbFcAAAYWaFF8rgAABhZo4B/vAAAGFmg/AUwAAAYWaGwEWQAADwNq9AIAABZobARZAFUI ARoDagAAAAAWaCNpDwBVCAFtSAAEbkgABHUIAQAGFmgjaQ8AAA8DagAAAAAWaCNpDwBVCAEGFmj4 PgMAAAYWaDZC1gAABhZo/TrlAAAMFWgXNJUAFmjRQr8AAA8DagAAAAAWaNFCvwBVCAEPA2pkAgAA FmhsBFkAVQgBGgNqAAAAABZo0UK/AFUIAW1IAARuSAAEdQgBNGATAABhEwAAphMAAA8UAAA/FAAA fBQAAMIUAADDFAAAkxUAAJQVAACZGQAAmhkAAMYcAAD6AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA APIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADtAAAA AAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAA AAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE AABnZFF8rgAIAAAKJgALRgEAZ2Q/AUwAAAQAAGdkNkLWAAAMLAAxkGgBH7DQLyCw4D0hsAgHIrAI ByOQoAUkkKAFJbAAABew0AIYsNACDJDQAqBGHfDicgAAMZ6VVKmxDTbb+zb/ImOhm///2P/gABBK RklGAAEBAQBgAGAAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicg IiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIAWgB4AMBIgACEQEDEQH/ xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMA BBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEB AQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2Fx EyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF xsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APM6KKK+6Pnhw606 mjrTqTLjsLRRRSGLSikpRSGLSikpRQAtKOlJSjpSAdS0lLSABTqaKdQMWlpKWkIdSikpRSAdSikp RSAcKUUgpRQAtKKSlFIB1OptOpALS0lLQAopwpopwpCFpaSloELTqbTqQC0tJS0ALS0lLSAWlpKW gQClFIKUUALRRRQAtFFFIBaUUlKKACiiigQoooFFABQKKBQAtFFFABRRRQBw9FFFdwhw606mjrXr /h/S0OgaZN4Y0Pw94hTy431KK82m8SZt28ZfCony7V4PrhuSeevWVJJtfp+JtRhz6HkdFeteEdL8 MXl14tibSbhLFprW0gS7hQ3No8zNEcFs7Srt1ySAozkiofDPhm103wZ4gGs6Yj6pNa3zwNKsciwr bAIxU8lW8yQjjrsB9CcXjYq6tqrfir/h1NFQbtr3PLKUV6T4K0vRodCsV1q3iMniO8ks4JJIhI0c KxsoeI4Ox/OZVyfY4wM1j6DpKadpHjG81K0imn023Fl9nkVW8uWWTZ5gbkAoVPTrnqKt4mN5K21v nd2/PQSpOy/rzOPpRXs8Wk20cEJ0Tw1oniHwv5e2WeABtQUbAWLMxB8zLEhVGeAPl4rj9Mi0nRvD N/4nh02LUs6p9hsYtRXcIk2M5aRVO1yVIGOgIyD2qI4tSTsv6fft8ynRa6nE0o6V0HiDXdL1yws5 ItEt9O1SNmWdrICOCSPqvyf3uTznt3yAvXaroOmp4Yu/D0NrEuuaRp8GoTMI1ExcljOryYwyKkiE AH05bGKqVflS5lZv/hr+hKp3vZnmdLXoH9qW3h3wD4ZuYtA0W9nvftXnS3tmJGOyXC85B6HHOegr O8QaTDqVr4b1TSrCK1n1vzIms4SQnnrLtLKWOFDFhheAuOppRr3eqsrtX9L/AOTG6emjOQFOr0Xx lpmjzaHero0EQk8PXkdpO8cQjaSJo1UvKcDe/nKy5HucYOak8R+HdMvfDGlnTLZIdZtdGg1C5VAE Se3KkO3oXVhk5wSG/iIAErFRaTatf8PUbpPU83pa7/UfCn9tar4ds9PhitkbQLe7u5IockDne+xR mRzwMDJJI+ouaD4CtbDx1pcGpTfadOuY5JbUT2rxG4eMco8bcpj73zZVgAOd2Ani6ajd72vYFRk3 Y82pRW9ptlp6eO9Ms7W6TUrBr23XzXgKLKpZdwKN25I564r1FNEvn1+5t9R8FaHH4fDTg3NvbJ55 iCtsKhGLbjhfurnnjBpVsVGna66X7fg+vkEKTkeJUorprTSZr3wJA9vFavPPrS2sf7kCZmaLgeaW xsyfu4685rSl8AWaJqUcXiW1nvNMtJJ7u2jhOVdVB2qScMM5Bb+E4BGTgW8RBOzZKpyexxIpRXYf DezW91fU1/s+1vp49Nlkt4LqNXRpQybcg8dTjOR1PNa/inTVi8HyXGvaNpejaus4Wxj0/apnX5d+ 5V3DAHOc9cDjPzRLEKNT2dv6fkNUm4cx5zSiu2ufCs2q6nolrHJYWsTaLDeXFwkIhWKLnc7/ADHe /TLcZ46AE1b8M+FtAfxfpSDW7XVrOeOWRIvJZWaRP4HQnKjHzAtw20jGCMksVBRv8xKjJuxwFOre 1Lw7aWuhS6vYar9ttlvhZofs5j3/ALoOW5ORg5XGO2c1pWvgX7Vdw2/9qxReboy6r5kse1EycbGO eAO7fpVOvTSu3+YvZybschS11+m+CYNUlu7i31WWTSYZBDHdw2EkryyFQxHlL8ygZ5Y8dMZzxzur 6Vc6Jqtxp14FE8DYbY2QQQCCD6EEH155xRGtCT5U9ROEkrspinCminCtCBaWkpaBC06m06kAtLSU tAC0tJS0gFpaSloEApRSClFAC0UUUALRRRSAWlFJSigAooooEKKKBRQAUCigUALRRRQAUUUUAcPR Vn7DL/eT8zS/YZf7yfmaf9o4X+dHf/ZON/59srjrXdaZr3g2W20qbV9L1G01LTtq+ZpBSNbkKQVZ 8kMH4OSpBPXPQLxwspAfvJ+Zpfscnqv51lVxmEqb1PuZrTyzGx/5ds7G68ffbovFVxJDNa3+rSWj 2ptzxD5DZGWyDnAHIHX0q/qHxHsdR1PUZxY3Fta3GiT2MVvGysq3EzB3kI4ABbILDk7QSOcDz/7J J6r+dH2ST1X86y9rgP5l/SS/Qv6hj/8An2ztbr4lanp8Njp/hi4ey060tY4cPbRbppAMvIVw20sT 03H1zkml8SeMdI1LSNUTSrS4tL3WLqGe9Vo0EexE+4CGOT5uX3bVJ3HNcV9lk9V/Ol+yv6rQq2AT TUlf8+uvfUPqGPas6bO9svFng6DUrTxAdH1Cz1mCPJtdPZIrR5QCAeu5QeMgcdiG53Zdl4rsr6HU rDxJaXEljf3x1DdYuqPbTENuKBgdwbIXDHgcjmuW+zP6rS/Zn9VoVfBL7f4vT0D+z8d/z7Z1cure Dob3RoLDSrv7BaXH2i7ubpEkuLjnPlFQwQphQOfU4H3t+na/FjV5deaTVD9o0OWRxLp/lRH902Rt 3bQWwCOuN2MHGa4L7O/qtAt39VpOtgZK0pp+o1gMctqbR2qaz4OvfDOlaTqo11m01rgRyWscKB1k kLAkMxwcBeOxzyetLbeMdJttb0mSPT7gaTokMv2K1kKSPNMxJ8x2ONhJKscbtpX5R6cV5DeopfJb 1FL2+D1vU79e+/5h/Z+O/wCfbO0tfiPqV/De6f4luHvdPu7WSHCW0W6GQ/ckC4XcVI6bh65yBVLU fFudV8O6jpYljn0rT7e2bzeA7x53D5TkoQcdsgmuY8lvUUvlN6imq+BTupJfkJ5fjmtYM9El+I1g PFtnqltpssNj/Zi6dc26N5bRruLHymUjG35cH5en8PBFSPxvZ2ni7SNQhXVbux0/eDJf3RluJPMU qxwSUXAIwFxnbyeeOH8tvUUvln2qFVwK+30tuV9Rx/8Az7ZswXulab4vs77T1vW0y2uoZlFwFMxV SpbOPlzkHH4V03/CQeDLfxBJ4gtF8RjUftDXSoWhSNnJJKEjJCHJB68E9a4HYfal2mrniMJLep0t uSsuxq2ps7K08V/arOC3xFDqcviJdU8yb5bZMjHzHO4ANyfbvXeX+jW2lQ+KNWfSZ7KW9064E1xN dxtCJGx8sQB3EOxzlgDwAAM4HiWKMVjUq4WTXLUSRccBjEtaTZu+GtZt9H/tf7QkrfbNNmtI/LAO HfGCckcce/0rFFNpc10rG4VNvnWpk8sxrVvZs7mLxrYxanpsjWUs9kuix6TfRv8AKzLzvKEH6Yzj PI46iKx8QeG9C8R6PfaNp1+YLTzPtMlzIvmzbwV4UHaNoPGMZ6HHWuM3ClDCsfbYPbn/ABK+oY7/ AJ9s7aDWfCf9kXOhzxa0NN+2reW8kZi84nywjBweAM5Ix1yOmObN14z0mW7mkt7K5ghfw+2lxw8N 5chPHJOSgHGevtXA7x70vmD0NJ1sG3dz/Ef1DHf8+2dj4Y8VWumaPdaRqB1CG3klFxHc6bN5cyPg Ag5IBUgd/wAjwRgavqB1XVbi98toxK3CPM8pUAAAF3JLHAHP5ADis7zV9DR5y+hq44nCRk5qauyH l2OaUXTZKKcKh85fQ0onX0NX9ew386J/srGf8+2TUtQ/aE9Go+0J6NR9ew386F/ZWM/59snp1V/t KejUv2pPRqPr2H/nQf2VjP8An2yxS1X+1x+jflR9rj9G/Kl9ew/86D+ysZ/z7ZZparfbI/Rvypft kf8Adb8qPr2H/nQf2Vjf+fbLNLVX7bH/AHX/ACpftsf91/yFH17D/wA6F/ZWN/59ssilFVft0X91 /wAhS/bov7r/AJCl9ew/86D+ysb/AM+2WqKq/b4v7r/kKPt8X91/yFH17D/zoP7Kxv8Az7Zboqr9 vi/uv+Q/xo+3xf3X/If40fXsP/Og/srG/wDPtlulFU/7Qi/uv+Q/xpf7Qi/uv+Q/xo+vYf8AnQf2 Vjf+fbLdFVP7Qi/uv+Q/xo/tCL+6/wCQ/wAaPr2H/nQv7Kxv/PtlwUVU/tGH+6/5D/Gj+0Yf7r/k P8aPr2H/AJ0H9lY3/n2y3QKqf2jD/df8h/jR/aMP91/yH+NL67h/50H9lY3/AJ9suUVT/tGH+6/5 D/Gj+0Yf7r/kP8af17D/AM6D+ysb/wA+2XKKp/2jD/df8h/jR/aMP91/yH+NL67h/wCdB/ZWN/59 szKK9Z/4Un/1MH/kl/8AbKP+FJ/9TB/5Jf8A2yvluSR9z/aOG/m/B/5Hk1d7exaJPpukCKLS3u0t MrEbiKNJpPLtsiVkKFcZnI3sCWU84IWtz/hSf/Uwf+SX/wBso/4Un/1MH/kl/wDbKahJdDKpjcNN p89reTOYvrLwxaX0J0q5+0Wj2l4PNuWT5mEDbCVJ3B95IGVTOE2gkFmt3mieHU1PV4NLNreQRx3E is13kwqtsJIzFhh5n7zeD9/AQZxyTuf8KT/6mD/yS/8AtlWE+Ed5HYyWKeLJ1tJG3PbrbkRseOSv mYJ4H5CnyvsZvF0NLVX26/fscFo1/af2K1rfmzjiN7bxPL9kiadbdxL5rKxQsSPl55I4x6VNf2Gi Qx3/ANmEDFWbcZLtQ0I8tCnlBHcOGkLqRmQhQoZkOXrr/wDhSf8A1MH/AJJf/bKP+FJ/9TB/5Jf/ AGylyy7FvGYbm5lO3yf+Rzc2meHJmZjdwKT4cS5GydFC3ihRsAH8R2nKnJJZj1xg0ez8M+bZG/mg itnhIeYS7pGDW0hlLIc7WSXaI/lUnqN/Wuk/4Un/ANTB/wCSX/2yj/hSf/Uwf+SX/wBsp8suxP1r D8tvav7n/kYFvpuhtHvFlp092ltczXtqL1jHAUjZovJKyZkDbQXwz4/2Kovpul2mtfY7VfPj+wXt x5kwyxBhlaE4wB/qxE4wMhnOeQAvap8I7yOxksU8WTraSNue3W3IjY8clfMwTwPyFN/4U9ceb5v/ AAlEvmeX5W/7Kc7NuzbnzOm35cenHSjlfYSxdDW9T8/6/pbnA293pkHgeeCWOJ9QuJ5FjxBGzoAY GDFyd6jAkAA4O5vSuistK8NTahp7zS6XJay2Fk10slyqNHKQVk24ljA4TLZ3sGYHacmtb/hSf/Uw f+SX/wBso/4Un/1MH/kl/wDbKXLLsOWLwzTtUav5P/IwNKsvDMHizRIp3s5rC80tWvDPcfJBMY23 c5G1sqOD0LcYO3EUFt4dhjuZLq105roQ5a3F47RRyCO5YCNlk+YHy7fPzNy5HBIA6T/hSf8A1MH/ AJJf/bKP+FJ/9TB/5Jf/AGynyy7CeKw7/wCXr/E43TINDt/EuqWd3LFLpyybIpZGB3RpcRliGXuY lk5XBOcDkgHTWPwzeafbNIbMTyTJLc/P5RjhaKMTSKBj51lSTZHzwxIQqRW//wAKT/6mD/yS/wDt lH/Ck/8AqYP/ACS/+2UuWXYcsXhm7+0f3P8AyOe0+z8O3cU1m/2CGRo7HypJLry1LmB2mLuSxXBJ HyjAcRgqRkHmNdFmuuXi6fHFHaCTESROXCr6biTk+pBKk52kjFekf8KT/wCpg/8AJL/7ZR/wpP8A 6mD/AMkv/tlDjLsVDG4aMub2jf3nk1Fes/8ACk/+pg/8kv8A7ZR/wpP/AKmD/wAkv/tlLkkbf2jh v5vwf+R5NRXrP/Ck/wDqYP8AyS/+2Uf8KT/6mD/yS/8AtlHJIP7Rw3834P8AyPJqK9Z/4Un/ANTB /wCSX/2yj/hSf/Uwf+SX/wBso5JB/aOG/m/B/wCR5NRXrP8AwpP/AKmD/wAkv/tlH/Ck/wDqYP8A yS/+2Uckg/tHDfzfg/8AI8mor1n/AIUn/wBTB/5Jf/bKP+FJ/wDUwf8Akl/9so5JB/aOG/m/B/5H k1Fes/8ACk/+pg/8kv8A7ZR/wpP/AKmD/wAkv/tlHJIP7Rw3834P/I8mor1n/hSf/Uwf+SX/ANso /wCFJ/8AUwf+SX/2yjkkH9o4b+b8H/kcP4Ra1S61BriK1lcWn7lLiSCMF/Nj6NMrIDt3dQeM4rpR Dozx6YWm0nyotRikuNy2ochpfmQlWBZF3uGbaFISMogXc1af/Ck/+pg/8kv/ALZR/wAKT/6mD/yS /wDtlUoy7HPPFYaUubn/AAZwWt6iLvTdKRY7BXaAyXH2e1hjbzBLKoyUUEfJs+Xp0OO9bNtFpUPj DxXaXcdnFE63NtaCYKqQyNMqIwz90LkkkchVYjpXSf8ACk/+pg/8kv8A7ZT5fgzJPM803iRpJZGL O72mWYnkkkycmlyy7DeLwtrKdt+j737GHrn/AAjNzbatqlnaacp3QSWkIn2NgrblozEjjA+aXO0E 538qVG5+vjw7ea/dG6NhHDJGJWubSfewJvmDMNrMGcwvuIIJGBgADFa3/Ck/+pg/8kv/ALZR/wAK T/6mD/yS/wDtlPll2IWIwyt+8enr5f5GNZ2Xg9Llo5Es542uQpea5dDGN1qrBdsmNo8y4IOW4jzu YAk19AXRbKy8PahKtgL0anCJWa6O4R75cu67xs24jP3QOFJZtxVeh/4Un/1MH/kl/wDbKP8AhSf/ AFMH/kl/9so5Zdh/WcO1Z1X+JyutW2j/AGK/lt49OF0kMAKQ3Xywny4B+5AJEpLGcNktjbkkH7xJ YaCNb0GOAWclvNpaSXgkuyE+0bHLbm3ja2QvyblBOBlc5rqv+FJ/9TB/5Jf/AGyj/hSf/Uwf+SX/ ANspcsuw1i8Olb2j/Hsc9dWvhNbue022sdqNz/a4bh3kUfbvLwo3FT+4+YDaSR83NZ2oJpces6At 1BYQWojT7fHYzeagHnybssrMSdm3+InpjHArsv8AhSf/AFMH/kl/9so/4Un/ANTB/wCSX/2yjll2 COLwy/5eP8Tm54UmuboainhqSVWJsIbWaOKKQ7sMC8TLhAhJHmMrZVQM5cF5tfCaaXOkK2sz+XMY biW4dZT/AMfZQldwGf3Vvxt/j5HzCuh/4Un/ANTB/wCSX/2yj/hSf/Uwf+SX/wBsp8suwvrWGtb2 lvRNHNyaPo4W1hljs7eaSyR4T9swZXazZy0u58RkS+XtzsBDHhh0sWi6TaaZrNgV0ttkEMm97oOT L9ilDFPn2uRM2BtBwXPopXfk+DMkzBpfEjOwVVBa0ycAAAf6zoAAB7Cmf8KT/wCpg/8AJL/7ZRyy 7A8Vh2rOp+DOensdCuZ7s2FlYF7We6SKP7U4hmjV4VjeV2k+UFXkIYMoZgo56GjHJbaP4v1uySKz FpG14sa3UEcoUxpL5QBkBOdwXv8AMcA5rt7P4R3mnTGax8WT2srLtLwW5RiOuMiTpwPyqKX4MyTz PNN4kaSWRizu9plmJ5JJMnJo5ZdgWLw+sXUuvn/kcxb2fhm5udOlM0E1zPD5k8E8v2aAyFo9wZl+ 4BuuMY2/6tMK2QZGRJ4fdJXngsHeGC3dP3zJ5jfYHZlIVhn98iZxhtzEE84rp/8AhSf/AFMH/kl/ 9so/4Un/ANTB/wCSX/2yjll2H9aw3/Px/j/kclc2vh97aeWJbWPdAruEuGJgc20bIIgWJfdMXRgd +0D+DrVy607w7d6pOiNEIJr9lV7R90u43O3y441zmPyPnDBD82AGP3K6H/hSf/Uwf+SX/wBsp8Xw ZkgmSaHxI0csbBkdLTDKRyCCJODRyy7A8Xh+lR/j/kcfeWNnbX1hnRLWZprA3Mtva3xMY8uZ2dg+ 985iiZcBjgkkcjFcnXsl18KNRvXd7vxfdTu8YiZpYGYsgbcFOZOm4A49eaqf8KT/AOpg/wDJL/7Z ScJdi6ePw8V70/zPJqK9Z/4Un/1MH/kl/wDbKP8AhSf/AFMH/kl/9spckjX+0cN/N+D/AMj1miii ug+WCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiis7V9bstFhRrlm aaQkQ28Q3SzH0Vf5k4A6kgc0m0ldg3bVl+SRIo2kkdURQWZmOAAOpJrkrvxNe6m2zQPKitR1v7mI usntGmRkf7ZIHoDnIpXS3muyCXWNq2wIaPTo2zGuOhkP/LRu+Pug9ASN1XK8fFZnb3aP3/5HnV8b 9mn95W+1+Kv+g1Yf+C0//HaPtfir/oNWH/gtP/x2rNFcH9oYn+b8F/kc31ut/N+RW+1+Kv8AoNWH /gtP/wAdo+1+Kv8AoNWH/gtP/wAdqzRR/aGJ/m/Bf5B9brfzfkVvtfir/oNWH/gtP/x2j7X4q/6D Vh/4LT/8dqzRR/aGJ/m/Bf5B9brfzfkVvtfir/oNWH/gtP8A8do+1+Kv+g1Yf+C0/wDx2rNFH9oY n+b8F/kH1ut/N+RW+1+Kv+g1Yf8AgtP/AMdo+1+Kv+g1Yf8AgtP/AMdqzRR/aGJ/m/Bf5B9brfzf kVvtfir/AKDVh/4LT/8AHaPtfir/AKDVh/4LT/8AHas0Uf2hif5vwX+QfW63835Fb7X4q/6DVh/4 LT/8do+1+Kv+g1Yf+C0//Has0Uf2hif5vwX+QfW63835Fb7X4q/6DVh/4LT/APHaPtfir/oNWH/g tP8A8dqzRR/aGJ/m/Bf5B9brfzfkVvtfir/oNWH/AILT/wDHarXer+KLXy0XV7Oa4mO2G3i00l5W 9B+9/MnAA5JAqxNcyvdLYWEP2m/ddwjzhY1/vyN/Cv6nBABro9F0GHSt9xLJ9p1CUYmumXBI/uqP 4UHZfxJJya9DByxdd80pWj6LX8Dqw7r1NW9PkWNGTVE0mAazLby6hgmVrZCqZzwACSeBgZ74zgVf oor2D0AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4vV/FN9a63e2cF/o 1rPbuqWmmX3y3GqEorDynMqBQzMYgdjgMjHnlRqS6hrGoanfwaMbGOPTJVhnW8jdjcyGNJdqsrDy l2yIN5DnLN8mFG+PWPDupamNSs01iNNL1RCl1BNbNLKitGI3EL+YFjBUZAKNh2ZjnOBYudFvkv7m 40jU47FL5w94r23nMXCKnmREsAj7FUfMHX5FO3728Ap614puNMurBUscRmJbnURKwLWcTSxx/OVJ VMeZJIWJKlbaQDjLoJe+JL/WtaSwudKS1067S3S3ntZC837iKU5lEmEyZSufLbGM4bpRceAtC1Oe 8k1qyg1TzYktoGu0LyW9uqYCCRiWLbzI/mZDkuMk7QajsfDniOxluyniS0YXzxSXUzaZ+/MiwRQu 6Hzdik+VuAMbBSeQwGKAI7vxv+40e9sLXfY3VpFqF20pw1tbyPEil8EhOJJJCxJG22kHqyXLDxLN N4u1PRru3jjgjuPJs7hSfnZbeGVo3zxvxKWXBOVR+Bsy1c/Drw5cC4j1LTbS+g+zxWVos0WWtLWO MKsSOSWzuMjbwQ3zgZ+VasWfhRhpt/b6lqUl3cXtxBdvdRxLEyzxRQIsgXlc74BJggrztIIHIBTs vHSf8I9pt/eWU8sj6VBqeovaKojs4pEJ3kO4Yr8kvCb2wh4yVzqaFrV3qmreILS4sJLePTr1beGR in71TDG+eHY5y+7oPldB94MBz8vw0tpLfTInk025e10y302WW+0tLhtkQbDw7mxE53sTuEg4Tg7T u6jTdKm0/VtZu2uY5INRuI7hIhEVaJhCkTAtuIYERqRwMc9ewByfhLxrea22iGTVtD1KTUYg9zZa bEVmsMxGQtIfOf5QwEZyq/NIvIPynUs/GTL4V0rWL7TbuRJtMhv7+4tY1EFqjJuZjvcFgMMdqb2A AyPmXduaFpn9ieHtM0nzvO+w2kVt5u3bv2IF3YycZxnGTXH6r8MU1Tw9ZaRJqMDLbaVHpwmuLBZm jKIQJYAzYiZiRv8AvFlVAChUNQB0Eni6zi1i509rO+22t3FZ3F35Q8mOSVYzEM7stuMqr8oJU8sF UhjJb+KLa51RLQWl2kE1xLaQXrBPKmnj3+ZGoDFwR5UvLKFOw4Jyu6O48MfaP7S/0zb9t1W01L/V Z2eR9n+Trzu+z9eMb+hxzT0zwPbaZ4lfVY103BuJ7lZBpqC7Lyliwe4JJKAyNgKqnAQFiA24A6yi iigAoqtf6haaZZvd3s6QQJ1dz3PQD1JPAA5Ncje6hqHiDKES6fpZ/wCWQO2e4H+2R/q1/wBkfMe5 HK1jXxFOhHmmzOpVjTV5GjqfihnnksdDWO4uUJSW5fJgtyOoOCN7D+6p47leM5drYrBNJcyyyXN7 KMS3MxBdvbjhV9FUAD0qeGGK2hSGCNIokG1ERcBR6ACn187isbUru2y7Hk1sTKrpsgooorjOYKKK zNc16y8P2Iur1nwz7I4413O7YJwB9ATzgcU4xcnZblRjKbUYq7Zp0VU0vU7XWNOhv7Ny8EoOCRgg g4II7EEEfhVuk007MTTTswooooEFFFFABWXqPiPSNJvYbO+vo4J5uVVgTgZwCxAwoz3OBWpXJ+If Adn4h1Zb2W7mhV0EdxEgB81RnGD/AAnnGeePQ81pSVNy/eOyNqCpOdqraXl+B1lFAAAAHQUVmYhR RRQAVVQ3WqXb2Olbd0ZxcXbjMdv7Y/ifH8PbqccArZW1z4jci0ke30sHEl4vDTeqw+3q/wCC5PK9 lZWVtp1nHaWkKwwRjCoo4Hr9STyT1Jr18FlzlapV27HoYfCc3vT27EGlaRa6PamC2ViztvlmkOZJ X7sx7n9AMAAAAVeoor3EklZHppWCiiimAUUUUAFFFFABRRVdL+zkitZY7uB47vH2Z1kBE2VLjYf4 vlBbjsCelAFiiqcurabC86S6haRvbo7zK8ygxqiqzFueAFkQknoHU9xViSeGF4UlljR5n2RKzAF2 2lsL6narHA7AntQBJRUYnha4e3WWMzoiu8YYblViQpI6gEqwB77T6VGL+zazhvBdwG1m2eVMJBsk 3kBNrdDuLKBjrkY60AWKKKKACiiigAooooAKKKKACiiigDH16+uLdtMsbWTyJtTuzai4ChjABFJK zKp4LYiKjPALAkMBtOWmu3eiaydHvpZNQgR7QtqEuxJEW5aaNA6ooVz50SICoXiUEj5GZug1LTYd Tt1jkaSKSNxJBcRECSCQAgOhIIzgkEEEEEqwKkg57eF7aXS720uru7ubm9QLLqEhQXAK5MbIVUKh jPzJtUANlsbixIBzd98UbOxgS4lisYYTaf2hi61AQyXFqzyCJrdCp8yR0i3eW2zaXRSck40NV8T6 j9q1C2tLP7PDYarYWT3jSq3m+dLallVMHHyTOCTjHylSSTs1LnwvbSXCS2V3d6Ygt47SWKwKRrLA hbZHypMYXe4BjKMN3XhcSTeG7Of7buknH2zULfUJMMOJIfJ2gcfdPkJkdeW5HGADHvfG0trr0ujx 2VjPfP5qWlkmpp9rkkSJ5V8yLbiKNwhw+5iN8eVGSF2NF8Q2+vz3D6evm2EcUDpdZK73kTzNmwgE YjeFs9/MxwVIqvH4Rs4tYttQW8vttrdy3lvaeaPJjklWQSnG3LbjKzfMSVPClVJU2PDOjf2Ho4tm SBJpJZJpFgHyJuYlYwcDcsabIlOB8sa8KAFABycvi3V7Xwx4mmu5o45401N9JuxGBuaCS4UREcqX RYkcZxvUn5T5bsdS/wDH1nY+KG0djY/uruCzkje+CXbSTCPa0cG354x5qZbcCMScHaN2hfeDtL1H w5d6Hc+e1vcS3M3mq+2WJ53kZyjAcf61175UlW3AkGw3h9P7Ykv4dQvreOeVJ7i0hdVjnlVVVWY7 fMHCRgqrhSEwQQW3AHL6T431SDT79dasIGvvNuhpyw3O4XbpeNbiHPlr5e12t0DsPmEgY4w4XU/4 TZb2WJNEtI71Lp4IbSeWZoY3lkge5Kv8hZAIVRgQrZMoXAwxFyDwhYRSwvJLPP5GoT38QlEZCmVj I0fCgmMSESAHJDohz8owL4QsINOjtbKWezkhu3u4LmAR+ZC7BkAAZShVYmMShlO1AoHKggAr2viy 4vb/AEqyt9K3TXf2sXDG4AS3NtOkMpyRl1JZtpABOFyFDMUj8CeKG8T6Dp8ySR3ZjsoRf3iuoH2t o0ZowqjBIDZY8BSVUZO4JqWHhuz066s7mKSd5raK5j3Ow/etcSpLK7AAfMXTPy4UbiAAMAN0vw/Y eH47aSCeVEtNOisHaV1xJFDny2c44K7pORgHecg4XaAbVYmseJINNm+xW0RvdSZci2RsBAejSN0R f1POAcVlXviO61jMOiObeyPDaiy/NIP+mKnjH+2wx6Bs5Fe0soLGExwIQGYs7MxZnY9WZjyxPqea 83F5jGl7tPWX4I46+LjD3Y6sjW1nurxb/VZxdXi58sAYit89o17e7HLH1xwLlFFeBUqSqS5pu7PK nOU3eTCiiioJCiigkDqcUAFZmuaDZeIbJbW9EgCPvjkjbayNgjIP0J65FadFOMnF3W5UZShJSi7N FPS9MtdH06KxskKQRZwCckkkkknuSSTXN+PdW1zS7az/ALIWVI5Gbz7iKASshG3auCCAGy3OOwHe uwoq4VOWfPJX9TSlV5aiqSXN5PqUdGnvLrRbKfUIfJvJIVaaPGNrEc8Hp9O3Sr1FFZt3dzJu7uFF FFAgooooAKKKgu7uGyh82ZjgkKqqpZnY9FVRySewFCTbshpN6IydRuprjVbmxXUn0y3s7WO6luYh GWbe0igZkVlVR5RJ4ydw5XB3Z97qd2g02PXRpdpBdJLIkd/fGxiu0jKAl2ZWZN3mIwhwSRu3NhcP 0cfgmfWLmLVdRu7jTLtCphhtBE5VRkr5u9HV2BJI4whJ2nkk70/he22Wf9n3d3pk9okkcdxbFHcp IytIG81XDFmRWLEFiRndy2focJgFBKdRa9ux6tDCqNpTWpz0niq5uTHcaZI0FhPbaFPbxPEgKJdX bpID15MYVepxjjB5qXVfGlw/g1L+zg+zXV74autYhfeH+zvHHEVXBXDczDk4+70543J/CtjPMZWm u8lLFOZd5xazNNHlmyxJZiGJJJHoeaz/APhAbI28tpJqepSWZ0yfSre2YxBbW3lCAqhEYYkCNAC5 Y8c5JJr0ztJNX8YJo3iG2025SxSOeWGFFfUFW7lMrhFeODB3RhmwWLKRskIUhRu0NA1m41pb2WTT /stvBdz2sTmYOZjFK8bMAB8q/IMZOc7hjADNXv8AwjZ3+otdNeX0SPdwX0ltDKFjkuITHtkb5dx+ WJFK52YGdofDDU0zTYdKtXt4GkZHuJ7glyCd0srSsOAONzkD2x160AXKKKKACiiigAoorI1HxRoO kXX2bUdXs7afaG8uSUBgD0OKANevL4NE1G9ttRtYbfM3hqJ7bSYQ6gNItyLmCFyTyoig0/nIOJHB bdkr13/Ce+E/+hg0/wD7/Cj/AIT3wn/0MGn/APf4UAcLqc80nhjUbgSyGDVNC1/UAdx/0iNpIvs8 jDuRAyKu7lV+XjGKk02xuI/G3h+G4jxBomoS6ZZDcP3KNBeyBOOW/wBHFgcnP13b67b/AIT3wn/0 MGn/APf4Uf8ACe+E/wDoYNP/AO/woA5XSpNSTxBZ+LpbS0TS9UvZUFytyzMbe4EUVu3k+WCpc29p /GxHmOSq5/d6GnmEapp+pGOQaDNqdw2n5cYiuJd489mxzFKzTCP5iMzpjd5iLDtf8J74T/6GDT/+ /wAKP+E98J/9DBp//f4UAdFRXO/8J74T/wChg0//AL/Cp7Lxh4c1G9is7PWrKe5lJEcSSgsxAJOB 34BoA26KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoormdT8UM80ljoax3FwhKS3T8wQ HuMj77j+6Dx/EV4zFSpGnHmm7ImUlFXkzV1fW7PRoUa5ZnmlJENvEN0sxHZV/mTgDuRXKXK3muyC XWNq26kNFp8bZjXHQyH/AJaN3/ujsCRup1rYrBNJcyyyXN7KMS3Uxy7+3oqjsoAA9OTVqvBxeYyq e7T0X4s8uvi5T92GiCiiivMOIKKK4HUtL8VyeP4rq2ln+wedEyOs+IkhG3erJnkn5uxzkcjHGlOm ptpuxtRpKo2nJKyb1/L1O+ooorMxCuJ8e+FdS8Ry2T2RgljiDK0E77VVjjDjg5OMj19OprtqKulU lSkpx3NaNaVGaqQ3RXsIJbXTrW3nnaeaKJEeZusjAAFj9TzViiiobu7mb1OD8d3PimHVLRdGW8Fq YwVNpFvzNk8ScHC424zgcnNdvbGY2sRuAonKDzAnQNjnHtmpaK0nU5oKNrWNZ1eaEYcqVuvV+oUU UVmYhRRRQAUUVh634kh0y4g0+ALNqVy2yKM/dT5Wbc5HQYVsDqccdyKhCU3yxWpdOnKpJRirtl3V NWg0uJNytLcS5ENun3pCOv0A7k8D8q5a509NXk8/W4be8k/ghdA8UI9FB7+rHk+wwBRZtQOtXEcE 0Et2kEU881yjEzbmcCNSpHlKPLPZvvZwSDuhn8WWbXUtnZur3MVzFEwYgggzpFJwDuUqXwNwGTyN wzXsYfCqlruz6XBYGnh1zT1l/Wxd/wCEZ0D/AKAem/8AgJH/AIUf8IzoH/QD03/wEj/wpsOpXk/h W01KOFXup7aKVlRSwXcFLMFBywUEnaDk4wDk0y38QRGECf8AeSr5AdoVIUmWZol+VuVIZTuU8ryM sRXT7x6HudiX/hGdA/6Aem/+Akf+FH/CM6B/0A9N/wDASP8Awqhp/is3GnWDTadctf3KRN9ni8sb t8buHUl8BT5cmATu45HIpl9450y3jl+zBruVbbz0RWVC/wC780DDHcBs+YttxjjJb5adp3sF4Wua X/CM6B/0A9N/8BI/8KP+EZ0D/oB6b/4CR/4VpRO0kSO0bRsyglHxlT6HBIyPYkUhd2uI7W2he5vJ c+VBH95sdSeyqO7HgfiKlOTdkNqKV2ZU+geHLePzJdF00DIAAs0JYngAADJJPAA5NdR4Y+GWnG8t 9X1LRrK0MLiW2tI7dFdWHIeRgOvoo4HfPQdJ4d8Ix6bImoaiyXOp4+Uj/V2+eojB79ix5PPQHFdP XZTpuOstzhq1lLSK0CjoMmquoajZ6VZSXl9OkFvH1dvXsABySTwAOSeleN/EPxLrGrW6z2guLSxM c9utqCS0xaNmRpVB25MiRqqc/fKnO/aNJSUdzGMHLY7TXPGcl2z2fh+QbB8smo4DKPaIHhj/ALR+ Uf7XIHNQQJbqwTcSzFnd2LM7HqzMeST6muA1PUNQt7eeIS3Ea2cd3bxESOpHyXLJuIPzMscMBUtk 4k3cllYW7zXtTtrmwMrSt9heSGeMDZ9un8ucIOB8pbykYIM589ODhSeWpzTO2lyU0dzRXHQ32pW6 /Yro3aXwlgltPtDIGuCx2yrtRmBThmbr5ayAhcIudITM3g6OYXsqyFFaaabcjbtw8xX25MXO5SR/ qucY21k4m6nc36K5OHxFJaxW8JZQsrWyWxuJN7Tb7ho5Nj8eYqpsZWxkqys2d1V9G1+/k8MwFLm2 uplSyjF0VZ1DyuEZHG/LSIMMfmGd44Hc5GL2iO0rkNX8VXth4j+wRW8RiRo18tlPmTbscoc8dcdD yppZPFGofbbW0SG2jeR2gM0pVUkcTPESoaRT8uwPsXeTuC5Xhjo+Gr241u00WCEQ6jrF3aGcSIoV IwCodnIzsALAHHUggDOFqowfa4e0j1NpmkaaK2t4XuLqY4igT7zHufQAdyeBXd+G/C6aP/pl4yXG qSLhpAPkiU/wR56D1PVu+BgCx4f8OW+hQM2/7RfSgefdMuC3+yo/hQdl/E5JJO1XVSpKGr3OGtWc 9FsFFFFamAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAec6x4ol1S8uLKdNRsLCGRomiis5zL cYODudVIVD6KckYyQMrTYdb0u3hSGGC8jiQbVRNNnAUegGyvSKK4q+BjXlecn+H+RzVcMqjvJs86 /wCEhsP7l/8A+C64/wDiKP8AhIbD+5f/APguuP8A4ivRaKw/smj3f4f5Gf1Cn3Z51/wkNh/cv/8A wXXH/wARR/wkNh/cv/8AwXXH/wARXotFH9k0e7/D/IPqFPuzzr/hIbD+5f8A/guuP/iKjPijS1nS Am9Erqzqn2CfJVSASBs6Asv5ivSa5+8/5KHo3/YKv/8A0baUf2TR7v8AD/IPqFPuzmv+EhsP7l// AOC64/8AiKP+EhsP7l//AOC64/8AiK9Foo/smj3f4f5B9Qp92edf8JDYf3L/AP8ABdcf/EU0+JdN EgjIvQ7AsF/s+fJAxk42e4/MV6PXP3n/ACUPRv8AsFX/AP6NtKP7Jo93+H+QfUKfdnNf8JDYf3L/ AP8ABdcf/EVHP4o0u2gknnN7HFGpd3awnAVQMkk7OmK9Jrn/AB3/AMk88S/9gq6/9FNR/ZNHu/w/ yD6hT7s5h/EumxqGcXqgkLltPnHJOAPudyQKd/wkNh/cv/8AwXXH/wARXS+Mv+QHbf8AYV03/wBL Yad4wdk0W3KMVP8AamnDIOODeQgj8qP7Jo93+H+QfUKfdnMf8JDYf3L/AP8ABdcf/EUf8JDYf3L/ AP8ABdcf/EV6LVa/1C00uykvL6dILeMZZ3P4AD1JPAA5J4FH9k0e7/D/ACD6hT7s4P8A4SGw/uX/ AP4Lrj/4iqi+NdBfdsup22kqcWcxwR1H3OtSaz4ivvEO6CMS2Olngxg7Zrgf7ZH3FP8AdHJ7kcrW fHGkUaxxoqIowqqMAD0ArnngKCdk2/u/yOmnk8JK8m0T3XiQ36eTovmAn/WXU0LIsQ/2VcDc34YH U+h43xBqNtol9pkaQzTyQzNeTndlmUxyR7ixPzMS3/jvbiutqhqOiadqzRte2wlaP7pDspx6HBGR 7HitqNKFLRI9LDYOlh1aP39RJdP0/Vliu3RnWSMcrIyLKh5CuAQHXk/KwI+Y8cnKnRbFpnlMcvzu shjE7iPeHDhgmdoO5QSQOTnOcnN5VCqFUAADAA7VyXijw7qerapDcWkkZRYwqb5Cpt3ySXXA6nI5 HPA/DWOrtc6rLqdINNtBpsenCLFrGixom45ULjbhs5BGAQc5BAOc1XbQdNYwHyGBgZWUrK67yr7w Xwf3hDZb5s8knqTnQQMsaqzbmAALYxk+tOqbsLLsZtnoOm2Ag8iBgYGDRM8ruUwjIACxJ2hXYBeg 3EgZpn/COaWIfIWGVITB9naJLiRUdNmz5lDYY7cDccngc8DGqSAMk4Aq1ouh3niVhLG72uld7oDD z+0Weg/2/wDvnPUXFSk9CJuEFdlTTrG71OcadpKbzCAktzMzOkAx/GxOXfHO3OTwSQDmvRdC8PWW g27LbhpbiXBnuZcGSUjpk9gOcKMAZ6cmrthp9ppdlHZ2UCQW8YwqL+ZJPUknkk8k9as12QpqB59S q5vyCsXX/E1noKLGytcX0ozDaRn5m/2if4V9WP4ZOAee8W/EO00m9k0exuIV1BAPOnm/1cGfQfxt jsOB3PY8TFrWkRvJK+qRzXEzbpp5ZMvIfUn+QHAHAAFKpU5dEtR0qXPq3ZGvdT3mq3ovtUlEs658 qJM+Vbg9kHr6seT7DgFZv/CQ6R/0EIP++qP+Eh0j/oIQf99Vxy5pO7O+PJFWRpUVlnxHowKg6lbg t0G/rTv+Eh0j/oIQf99UuV9iuePc0qKzf+Eh0j/oIQf99Uf8JDpH/QQg/wC+qOV9g549zSorMGv6 Y8scME7XM8rFY4bWF5pGIBJwqAk8Anp2qcXE9xdRW/2DW7WF8mW6bRLtvLA7KoiOWPbPA5JzjBap yfQmVWEVdsu2ttearf8A2DTUVpgAZZXH7u3U/wATep9FHJ9hkjprDQrTQvG+jw2wZ5H0u/aaeTBe VvNtOWP8gOAOBU2l67oGjWK2dlYa4kYO5idCvizserMfJySfWqN14r05vHOk3AttZ8tNNvUOdFvA 2WltSML5WSPlOSBgcZxkZ7adNQR59Wq6j8ju6K5//hMtL/59dc/8EV7/APGaP+Ey0v8A59dc/wDB Fe//ABmtDI6CiszS9fsNYnuILU3SzW6o8kV1ZzW7hXLBW2yqpIJRhkf3TWnQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFc/ef8lD0b/sFX/wD6NtK6CufvP+Sh6N/2Cr// ANG2lAHQUUUUAFc/ef8AJQ9G/wCwVf8A/o20roK5+8/5KHo3/YKv/wD0baUAdBXP+O/+SeeJf+wV df8Aopq6Cuf8d/8AJPPEv/YKuv8A0U1AB4y/5Adt/wBhXTf/AEtho8Zf8gO2/wCwrpv/AKWw0eMv +QHbf9hXTf8A0thqLx1cRWnhyKeZiEj1PT3OFLHAvIScAck4B4HNAHS9Bk1kXmo+HdQtXtb280u5 t5Bh4ppY3RvqCcGs6SG88RHdqMb2uln7tiT8849ZiOg/6Zj/AIETnaLX9h6T/wBAuy/8B0/wryq+ a06cuWK5i1Bszf7C+HH/AECvCn/gPb/4Uf2F8OP+gV4U/wDAe3/wrS/sPSf+gXZf+A6f4Uf2HpP/ AEC7L/wHT/Csf7Zj/J+I/Zmb/YXw4/6BXhT/AMB7f/Csm/s/ATXJ0/StD8Jy3eP3k8trB5NuPViB 8zeiA56ZKg5rqP7D0n/oF2X/AIDp/hR/Yekf9Auy/wDAdP8ACj+2Y/yfiHszC07wp8ObG28t7Tw5 dSsxeSaeK3JZj6DGFH+yoAFUta0jwDFqvh1LfTPDAil1B0uAltb4KfZZ2AbjpvVD9QK6r+w9J/6B dl/4Dp/hVDUNF0oXulAaZZgNdMDiBeR5MvtR/bMf5PxD2Yz+wvhx/wBArwp/4D2/+FH9hfDj/oFe FP8AwHt/8K0v7D0n/oF2X/gOn+FH9h6T/wBAuy/8B0/wo/tmP8n4h7Mzhofw4BBGleFQR0It7f8A wreGuaMoAGq2AA4AFwn+NUv7D0n/AKBdl/4Dp/hR/Yek/wDQLsv/AAHT/Cj+2Y/yfiHsy9/b2j/9 Bax/8CE/xo/t7R/+gtY/+BCf41R/sPSf+gXZf+A6f4Uf2HpP/QLsv/AdP8KP7Zj/ACfiHsy9/b2j /wDQWsf/AAIT/Gj+3tH/AOgtY/8AgQn+NUf7D0n/AKBdl/4Dp/hR/Yek/wDQLsv/AAHT/Cj+2Y/y fiHsy9/b2j/9Bax/8CE/xrO1PxfplqY7azvLO6vZv9Wn2lVRB/ekf+FfzJ7A0/8AsPSf+gXZf+A6 f4Uf2HpP/QLsv/AdP8KP7Zj/ACfiHsyLTZ9GtJXvLrW7G71GVdslw06DC9diLn5EHp36kk81p/29 o/8A0FrH/wACE/xqj/Yek/8AQLsv/AdP8KP7D0n/AKBdl/4Dp/hR/bMf5PxD2Ze/t7R/+gtY/wDg Qn+NH9vaP/0FrH/wIT/GqP8AYek/9Auy/wDAdP8ACqF/aaXBMllZ6LY3OozDMcPkqAq9N7nHyoPX qegBPFXDNvaSUY07t+YOFupLrF/Z3uueFRaXcFxs1V93lSB8ZsrrGcGpPHJmXw3G1vHHJONT08xp I5RWb7ZDgFgCQM98HHoay5PDtpoes+GJI0ia9uNWc3E6RBN+LK6wqqPuoMnC/Ukkkk7Fh4n0HxF9 mhiE8kdxsmtmu9PmhjmK4kQxtKgVmG3eNpJwpYcKSPXV7amZjzW15rHjfT7PxLo2lG1fSr3EKXBu 0kxNaH5leJAMEKR1/DHMfhPwX4VudHuHn8NaNK41O/QM9hExCrdzKo5XoFAAHYACtiy8W+HtUuLK 6hW7zMgS2vLjS7iGMrIVICzPGFAchMDd8x2gZOKuf21o2n6j/ZaN5MjS4cxWz+Sksh3bXkC+Wkjl wdrMGYyLwS4ywPO7Xw7po8E/D4WXh3Rrie+e2e5huI1ijumGnztmVhG5YgksCVPPpnNegeF9Hm0e yuY5YLS0Se4MsVjZMWgtF2IuyM7V4LK0hwq/NI3B+8ZPtuhW2neaEgjt9Jl8hIxAQ1vIB5aokeNw Yq4VAoyyyLtyHGbD63p0dndXT3GI7WUwTAo29ZMgBNmNxZty7QAS+9SuQy5AM+z/AOSh6z/2CrD/ ANG3ddBXP2f/ACUPWf8AsFWH/o27roKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigArn7z/koejf9gq//wDRtpXQVz95/wAlD0b/ALBV/wD+jbSgDoKKKKACufvP+Sh6N/2C r/8A9G2lb7MqKWZgqqMkk4AFeWa74xubzxxpsvh426xw2F3GLq7haWOcNJbltiq6HAKrhs4POBjB KlJRV2aU6U6r5YK56pXP+O/+SeeJf+wVdf8Aopq5L/hK/GH/AD+aH/4LJv8A5IrI1bxN4s13StU0 tZ9Hls5LaaC8njsJUEalCGVWM5Bfnpggd+wOM8TShHmk9DongMRBXlH8V/mdz47v0i0y1soAJ9Qk v7KaG1U4LKl1ExJP8K/LjceMkDqQKgv9NmkWDUdVlW4vlurfylTPlWwMyAiMHvjgueTz0HyjFYX1 jZn9/bTTS3MDzXEkDGWVxIuCx39AewAAHAxVzUdS1V7VA8tmR58J+W3YciRSP+Wnrj/61fO4zM3X 9yGkfzBYSpHdHY0VzP8Aausf89rH/wABn/8AjlH9q6x/z2sf/AZ//jlebzxNPq1XsdNRXM/2rrH/ AD2sf/AZ/wD45R/ausf89rH/AMBn/wDjlHPEPq1XsdNWdNNfS6pLa2s1vEkUMchMsLSFizOOzrjG z9ayv7V1j/ntY/8AgM//AMcqxolxc3Or373TRM4ggAMUZQY3S9ixoUk9iZ0ZwV5IveTrH/P9Y/8A gG//AMdqGaw1WeW3ka/swYJDIuLNuSVZef3voxq02oRxPei4HlLaoJS33sxlSd3A9VcY6/LnuKon WL1YbqeTT4kiswDcA3JLr+7WRgoCYOA2B8wzjtVGRa8nWP8An+sf/AN//jtHk6x/z/WP/gG//wAd p1vqSTanc2LRsjwn5WzkSAKjN9MeYo59RjPOJrC6+26dbXezZ58Sybc527gDjP40AQ6dcXErXcVy 0TyW8wj3xIUDAojdCT/ex17Verl5b2/ttY1RLWS2VDOpIlhZznyY+4cU7+1dY/57WP8A4DP/APHK lzSNo0KkldI6aiuZ/tXWP+e1j/4DP/8AHKP7V1j/AJ7WP/gM/wD8co54j+rVex01Fcz/AGrrH/Pa x/8AAZ//AI5R/ausf89rH/wGf/45RzxD6tV7HTUVzP8Aausf89rH/wABn/8AjlH9q6x/z2sf/AZ/ /jlHPEPq1XsdNRXM/wBq6x/z2sf/AAGf/wCOVjal4r1szSWGnXFgbkDEs/2Vitvkcf8ALTDP3C/i ewOlKLqy5YbgsLVbskdbeX8z3X9naYiS35AZ2fJjt1P8cmP0Uct7AFhpaXpUOlwuEZ5p5TvnuJcF 5W9Tj9AMADgAV5tp2s+J9LtfIt7vROSXeR9OmZ5HPVmP2jkn/wCt0Aq3/wAJX4w/5/ND/wDBZN/8 kV9NhKNHDx0d31YSy/FP7P4r/M63xD/yHPCf/YVk/wDSK6rL8E+GZ7fw54an1TUNSmls7KF4rG6S KNbWUwbDgLGr5VXdMOzdTnJAI5bVtR8Ra1FBHe3elf6PL50TwWt1A6PtZMh47pWHyuw69DWf5Guf 9Bb/AMm9T/8Ak6uz20O5P9m4r+X8V/mdLoWgata+HvBw1C/1W609YrUXemSwRL9lkVEeFvkiEu1J URSpOeQzNtRw1y8trlPDGueEvsd22oak9+LaVLd2tylzJK6u0wGxAok+ZWIbKNtVspv47yNc/wCg t/5N6n/8nVRiOvNr13bHWZCkdrBIFN5qO0FmlBI/0zOflGckjgYA5JPbQ7ieXYlfZ/Ff5no99aXM mqXetpp0jWdtexb7PY+bwR4VropnJeMn5BsJcQAjeTA0WheaUsnjWxf7NIbOa3lurrG7ynuYmgWB 3H3S4VpMZ5OxDyYkK+beRrn/AEFv/JvU/wD5Orc8H6JqetXU1xqF7dPpSKUSW31LUYmlkz/CWunB UcgnHXgdDio1IydkZ1sJWox5qisvVf5nY2f/ACUPWf8AsFWH/o27roKy9K8P6fo1xcXFp9qae4VE klurya4YqhYqAZWYgAuxwPU1qVZzBRRRQAUUUUAFFFFABXHeOviDa+CPskc1jNdT3Su8eHEcYCFQ dznpy69Af5V2Nc/egH4haOCMg6Tf5B/662lA1a+p5ofjreMcrounqOwN+Wx+OwfyqzY/HTfcxw3e gq+84H2K782RvZYyoyfxr1NtE0l2LPpdkzE5JNuhJ/SpUtLbToJXsrCNSFLeXboiFzjoOgyfcge9 Kz7m8qlFqyh+Iml6hBq+k2WpW277PeQJcRbxg7XUMMj1wat1wfgvXdRh8C+Hok8J6zOiaZbKssct mFcCJfmG6cHB68gH1Arc/wCEh1T/AKEzXP8Av9Zf/JFM5zoKK5//AISHVP8AoTNc/wC/1l/8kUf8 JDqn/Qma5/3+sv8A5IoA6Ciuf/4SHVP+hM1z/v8AWX/yRR/wkOqf9CZrn/f6y/8AkigDoKK5/wD4 SHVP+hM1z/v9Zf8AyRR/wkOqf9CZrn/f6y/+SKAOgorn/wDhIdU/6EzXP+/1l/8AJFH/AAkOqf8A Qma5/wB/rL/5IoA6CufvP+Sh6N/2Cr//ANG2laulajDrGkWWp2wcQXkEdxGHGGCuoYZHrg1lXn/J Q9G/7BV//wCjbSgDoKr3t7badZy3d5OkNvEMu7ngf/X7Ad6razrVloVl9pvHPzHbFEgzJK/ZVHc/ oBkkgAmvOdQvrzXbxLvUsKsZ3W9opykHuT/E+P4u3QY5znUqKC1OvC4SeIlaO3VljW9buvErmN0e 30kH5bZuHn/2pfQeifi3PC87eSxweJrGWV1jjSwuizMcBRvg6mtC5u47UIGDvLIdsUUYy8h9AP69 B1JApLXQ2n1uzvdWSN5khlaG3HKQ/NH1P8TdDnoMDA4yfLxOMjS96e/RHv8AJTw1P2dNa6fn1Ftr K51rDyebaace3KSzj+aL/wCPH27z+I9TsPDugGHySBKjQW9vAoyTtPQZAAHrmt+s3WdDsdetUgvo 2IRt6OjlWQ4xwR7HpXgSxPtqqdb4eyMptz1YxdRttW0W2vrRi0Ms0RGRggiVQQR6ggg/SpNZvLay so5Lq5hgQ3EIDSyBAT5inGT7A002NtpmkW9naRCOCKaEIuSf+Wqk8nkknJzWX4t8Ky+ImtJYLtIZ bcOu2VC6lW25PBGD8v49KzpxpSq2k7RuQ03dHTggjIOQaKp6TYDStJtLBZWlFvEsYdurYGPw+lXK wkknoWgooopAFXNB/wCQtf8A/XCD/wBClqkzqpUMwBY4GT1NOsr1tO1C5la0nnSaKNQYinBUvnO5 h/eFXDRmGJTlTsjbv9N+2XELhtqH5Lhc48yMHcAeOfmAGDxtdx3psWj239o3V5cWttLLJOskUjRh nQBEUckccqTx61W/4SNf+gXffnF/8cpreJ40ZFbTb4FztUZi5OCf7/oDW3Mu55vsp9mW2013e8cy KjyXK3EDgZKFY0Xnp12sCAeVYjIzVjTbZ7PSrO1kKl4YEjYr0JCgHH5Vnf8ACRr/ANAu+/OL/wCO Uf8ACRr/ANAu+/OL/wCOUcy7h7Kf8r+4z7j/AJDOp/8AXdf/AEVHSUwSNcXt7ctC8KzShlWQruwI 0XnBI6qe9PrCW56tFNU0mFFFFSaBRRRQAUUVzt5qUmqs1vYymOyBxLdIcGX1WM+nq/4Dnkb0KE60 uWI0m3ZEmoarLdyyWWmybVQlZ7sc7D3VOxb1PRfc8CK3t4rWFYoU2oO2cknuSe5J5JPWliijgiSK JFSNBtVVGABT6+ioYeFGPLE7qVJQ16hRRRWxqFFFFABXE3HiCe08dTRJDGUkMFm0TZ8xgCxDrz0/ enjByF6iu2q5oXh3/hJboXMqbNLiJRphw9yc8oh6hM/eYdeg7kaU48zscmMqxpQ55O1h2haFJ4kl 8yTdHpCNh3U4NyR1RT2XsW79B3I9JiijgiSKJFjjRQqIgwFA4AA7CiKKOCJIokWONFCoiDAUDgAD sKfXbCCgrI+YxGInXnzSCiiirMAooooAKKKKACiiigArz34geKf+EO8RaPq76fLdQiyu7ckN5cau 8luy7nIIHEbe9ehUEAggjIPUGgatfU8UPx1vGOV0XT1HYG/LY/HYP5VZsfjpvuY4bvQVfecD7Fd+ bI3ssZUZP416m2iaS7Fn0uyZickm3Qk/pVi2sbSzBFrawQA9fKjC5/KlZ9zeVSi1ZQ/EzfCNnPp3 gvQrG6jMdxbafbwyof4XWNQR+YNbNFFM5wooooAKKKKACiiigAooooA5/wACf8k88Nf9gq1/9FLW R4r15NF8baQ8cJuro6XeokCMBy0trguf4V+VufbABPFZmj+LhY+AvDum6UEn1EaTa+Y7cx22YV+9 jq3cIPqcAjPLSR+X4utJpZXmnls7p5p5Tl5Dvg5J/kBgAcAAVlUqqOi3O/CYGVb35aR/M15Guby8 a/1Cf7ReONu/GFjX+4i/wr+p6kk1Xe4lmuTZ2EYmuh98k4jhB7uf5KOT7DJBbpc60cWjtBY/xXeP mk9oge3+2ePTPUdDZ2Vvp9stvaxCONecDkk9ySeST3J5NeFjMeqbcY6y/I911Iwj7OirIy4vCeku PM1KzttSum+9PdwK5+igghV9h+OTk05dD0i2u1tINKsYraeCXzYUt0VJPmj+8oGD+NbVcLcaJ4lf x+l+kr/YxKrCbz/kWHjdHsznJwe2M4Oa8mEp1nJznbS+pyyiux01v4a0G0uEuLbRNNhmjOUkjtUV lPqCBkUXHhrQbu4e4udE02aaQ5eSS1RmY+pJGTWpRWHtZ3vdj5I7WOU8X6XanRLCzgsLMxC6jjSB YYfMCnJKwLIPL3cDIPG0PWPNqum6d4bv7jR9L0+GWSN4Fu7a2WJZP9BN0JPLKnjtsYn3J6VZ+Iuo 30EVpZRWscllOd0hlt/OWR1ZSsZXpyRn1Pboa6aLTrPVILW/1PSLX7e9sEk82FXeMMp3R7iM4+Zg R05PrXbF+zoxlU1Tv1/MylBuT5TkZ5NG0+4kRvBuirPYpPPeGNUxGsSwyExHygXbbOuAdnIIzjBo 1jUrTUr6d4/CVheSpdpai7v7dtrAXCwMC5iIzub5QrNwGJwV2Hto9I02K2W2j0+0SBY3iESwqFCO cuuMYwxAJHQ45pk+h6RdTTzXGlWM0twoSZ5LdGaRQQQGJHIG1ev90elQsTTum09PN/5/15g6UrWT MbxHb6Xpmh2+mxaZbrBd3SxJFFYCZUOC7uIlVssER8Haw3bcjbmq+jT6FZaLaatFolnb6lKXtxHa WQiklmVijqikBgpZSfmxgfexzje1W8SyeB4bI3WoyBo7ZFXBwcFsvj5E4Uk+w4JwKk02yltoC928 Ut5K5kmkjiCAsQBgdyAAq5JJwBUKpalZ31ffcrl9/Qy7HwppcsBm1TQNFN1I5dljs0ITPYsR8x9T xk9q07vQ9I1DyvtulWNz5S7I/Ot0fYvoMjgVforF1Zt3uWoRStYoQ6HpFtaTWkGlWMVtP/rYUt0V JP8AeUDB/GqDeHtCsdQ0+a10fTbeZZyQ8VsiMPkboQPXH6VvVlalpUl7ciRJUAKBCGGdvXkfnSVS fd6ilFW0Qtx4a0G7uHuLnRNNmmkOXkktUZmPqSRk1LNoekXNpDaT6VYy20H+qhe3Rkj/AN1SMD8K vKNqgZJwMZNLS9pPu9CuWPYoWmh6Rp/m/YtKsbbzV2SeTbom9fQ4HIqunhTw7G6umgaWrqcqy2cY IPqOK16KftZ73YckexnXmgaNqNwbi+0iwuZiADJPbI7YHQZIzTv7D0j7B9g/sqx+xbt/2f7Onl7v XbjGav0UvaTta4csexnWegaNp1wLix0iwtpgCBJBbIjYPUZAzUEvhfw2S802haUTyzu9pH9SSSK1 JporaB5p5FjijUs7scBQO5Nc3cTS624MyNFpwOUgYYab/acdh6L+J9B04anWrz0b82ONNSfKkVNS tNP8TSwl9OtW0+3AEUjwKXlA6BSRlY/p972H3tNVCqFUAKBgADgClor6ClTVOChHZHfSpRprTcKK KKs1CiiigAooq9oWgyeJJfNl3x6Ohwzg4N0R1VD2T1bv0Hci4QcnZGGIxEKEOeYaFoUniSXzJN0e kI2HdTg3JHVFPZexbv0Hcj0mKKOCJIokWONFCoiDAUDgADsKIoo4IkiiRY40UKiIMBQOAAOwp9d0 IKCsj5TEYidefNIKKKKswCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiio7i4 htLeS4uJUhhjUu8kjBVUDqST0FAElcJr/i+S9Z7DQptsIJWbUF5+qxep9X6Dtk8rQ13xHP4jDW1t 5ltpB4bOVkuh791j9urd8DIOLLciGSOztIPPumX93AnAVemWPRVHr+ABPFctauop2fzPYweXq3ta +i7Gb4elttP8G6Q77Y0NpCcKvLMyA4AHJYk9ByTVPULO4udesJNT1LTNP8xJFt7K6hZyyM0fEuJV BJK9OnGOTWvpOjy6J4WtLtAb/UIbWKONmjLLAmFVikY5bauWIHzPjAIyAMLWtMtvEF+Lqe+KM0dt DdiCAkOJZ3hTaHYGNsqd6MDsPHzEHPjyxiqzai7R72u/uOqpV54KGyt+R3rQat/Z8UcV7YreK3zy mzcxleeAnmgg9Odx6HjnhbGHV45mN/fWM8W3AWCzeJg2Rzkytx14x+NYemeMjcaVphm0u7bUbuOE i2h8v5xJE7h1LSYCHypMBm3fLyORlmofEPSLWKb7IHvZktftMcaOiGT915oGGIcDy/nLbcY4yX+W vJ9hWbcFH8ifaU7c1zW+zeJf+gtpP/gsk/8AkirN9Dq8kwNhfWMEW3BWezeVi2TzkSrx04x+NVte 1W507w+L6GLyZ2kt02TRGYx+ZKiHKRtliAx4U8kcZpmn65Nd+HBqK2ck9x5kkAhjjaMyOkrR52tz GCVyQ33QcEnHMWqOKnZb22X/AAw7xT5fmOvJtYsNEndpre61AuBB5Fi+05IAUp5v1+YuAM5PTlkP /CU+RH5v9j+btG/aJAN2OccnjNXNKtLu3ikm1C5M13OQ0gUnyo/REHYD16nqewGhUuaWlk/kNRvq UH/tf+z4/L+w/bd37zdv8vbz0756frRY/wBr+c32/wCw+Vt4+z7927I9e2M1foqOfS1irGN/xUv/ AFCf/IlWb8awZQNONiI9vJuA5YNz2HbpWhRT59b2QuXzK1jbSWlokU1zJcyjJeWTALEnJ4HAHoOw qzRRUN3d2UtAooopAFFFFABRRRQAUUUUAFQ3d3BY2z3FzII4k6sfyAA7kngAcmmX1/b6dbGe4YgZ 2qqjLOx6Ko7muE8SR3eqXWkSXdtb3Be8Kx6fPJiFV8iU/Odrbm4Bzg4IwMck9uEwcsRLtHuFm9jc kafVp1uLxDHbo26C1J6Hs79i3oOi+55qzXCPaSSPHYvpenssetbUsDJm2UfYi2AfL4GSW+594n61 fvNMkSHSrWG1tNIle/dozYNuVW+zS7XPypk5AypGCBg5BIr6OFGNOKjHRHRTqcqajH+vuOsorA0i 8+2+I9SZo/KmjtbeKaLOdjrJP9DgjDAkDKspwM1SsGvJbm3sba9a1ill1KWVkjVnJW6AXaWBAPzn qCME8ZwRXKa+2Vk0v6vY6yiuGjvtQmlOqQ3nlXN3Y6UdhiVokMszKePvEct/Fn5zz93Ghf6rdWGp QRpd3M6JdW9m25IViLPs3B84dpNrl8xgKPl4+VqORkrExtdr+tf8jqaK5uyvtQN3ayzXnmxXOo3V oIfKVVREMxU5HJb90BnOMHpn5jRt4tZ8R+ENTvbuS8tbCXQ7q+DSG3UyyRqpKQqPn8nL4ZmBONoy Ccmo0nJ2RnWx1OlHmkv60/zPQdB0F/EknnTbk0dDhmBwbojqqn+56nv0Hc16THGkUaxxoqRoAqqo wFA6ACuL8Y6WJLbwnposbPVguo+X9n1HakU22zuOX2xso6bsBMZAwB2hh0ebR77w5HLBaWiT67JL FY2TFoLRf7PnXZGdq8FlaQ4Vfmkbg/ePbCCirI+axGInXnzzO8oryuTxnqsVvqpgv7uUyeHLvWLa e5itlUbAnlSQRoS6xNvY4ny3yqM5D52NV1rXNFGq2RvJL+4VNOdJI4YkdWurl4HWIHCAKEBTzC2C fnZxVGB3lFc/4TvNSubW/i1MTiS1u/Kj+1Pbm4KGKN/3ogJjDZdsAAfJsJGTk9BQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWTr3iG00G3Vpt0tzLkQW0f35SP5KO7HgfUgEvYaTk7 Itanqlno9i95fTCKFTgcEszHoqgcsT2A5rzfVdUvPEVwst6pgs0bdBZZyAR0aQjhm746L2yRuqG6 nu9Uvvt+pyLJcAERRp/q7dT/AAoPX1Y8n2GAMzVrbUbowx2ksC2/JmRyymT0G5eQPXHJ9fXjq1r6 RPfwmX+xXtaivLoizG9zqczW+m4CKdst2wykZ7hR/G36Dv6FPEBn8LeG3l0aFnneVRPcuvmOAQcy N6ngD0GemBilhvNdt4Uhht9IjiQBURA4CgdgB0p/9peIv+eel/nJXi1aeJqTTcVyrpf8zomqs3dp h4XebXPCMUerWxAz5aNgoZFUjZIO6nIBBGDlQwxxWi3hvSnNsfs7qbdldSk8i72V/MUyYb94Q+W+ fdyzHqxznf2l4i/556X+clH9peIv+eel/nJXNLB4lybirJ9EyPYy6xKHiO2tPB+h211pdkDJDcIk c1xLJKLdfLdASWbOwBmULnaDJnGaXwnptjrfhmOW4s3hRoms2SC4lSG4iCeUGKB8MdmF3HJ+UYPA xJqOua9Y6Xd3k0GmSRwQvK6DflgqkkfpVkaj4hAAEWlADgD95Wrw2J9ly296+/N+BPsXe3KaWsWc b6C1oLS4vAvliOJbh1csrKUJl3bhhgCWzngnmk0DRjo9mVlmMtxKd0rBm2A5JwoJJ6kkscsxJZiS awNO/wCEhsnuJ5H064urhg0srmToPuqo6BRk4HuSckk1f/tLxF/zz0v85KyeBxKi4Lb1KVKd+ZxO mormf7S8Rf8APPS/zko/tLxF/wA89L/OSsv7OxHb8SuSf8rOmormf7S8Rf8APPS/zko/tLxF/wA8 9L/OSj+zsR2/EOSf8rOmormf7S8Rf889L/OSj+0vEX/PPS/zko/s7EdvxDkn/KzpqyNRuNQjvkW3 V9mBsCpkOe4Y44/SqH9peIv+eel/nJVa517X7aeziaHTCbqYxKQZOCEd8n8EP501l2I7L7yZwnbZ nX0VzP8AaXiL/nnpf5yUf2l4i/556X+clL+zsR2/Erkn/KzpqK5n+0vEX/PPS/zko/tLxF/zz0v8 5KP7OxHb8Q5J/wArOmormf7S8Rf889L/ADko/tLxF/zz0v8AOSj+zsR2/EOSf8rOmqnqOpQ6bCrS BpJXO2KFOXkb0H9SeB3rF/tLxF/zz0v85KSC3fznurqTzryQYaTGAo/uoOy/z6nJrWjls3L95oio 0pydmrCRxTT3P22+ZXuSCEVTlIVP8K/1bqfYYAW8sbPUIhFe2sFzGG3BJow4B6Zwe/J/OrFFe1GK gko6JHbGEVHltoUn0fTJLKOyfTrRrSNtyQGBSinnkLjAPJ/M0+20yws0VLWxtoERzIqxRKoDkbSw wOuDjPpxVqiqux8kb3sMEUYlaUIokZQrOByQMkAn0GT+ZpqWtvG4dIIlcb8MqAEbzub8yAT6nmpa KB2RVGmWAeNxY2weNFjRvKXKopDKo44AIBA7EA06Sxs5rkXEtrA84UKJWjBbAYMBnrgMAR7jNWKv 6BoL+JJPPm3Jo6nBYHBuiP4VP9z1PfoO5qoRlN2Rz4itSoQ5p/8ADkXh/wALxeIpEmlgSPR4ZWkD KoBuJDndsPZTubcw5bJA6k131v4e0SzjvI7bR9PgjvRtulitkUXA54cAfN95uuep9a0I40ijWONF SNAFVVGAoHQAU6u+EFFWR8tiK868+aRXSws44rWKO0gSO0x9mRYwBDhSg2D+H5SV47EjpUkkEMzw vLFG7wvviZlBKNtK5X0O1mGR2JHepKKowM9dC0dftG3SrEfafN8/Fun73zdvmbuPm37V3Z67RnOB Viaws7j7R59pBL9piEE++MN5sY3YRs/eX524PHzH1NWKKAK9jYWemWcdnYWkFpax52QwRiNFySTh RwMkk/jViiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK4zxF4vbzZdN0R1M6EpPeYDJ Ae6r2Z/0XvkjaVKSirs0pUp1ZckFdmh4j8VR6QxsrJFudUZciMn5IQejyEdB6Dq3sMkcLtkkuZLu 6ma4vJseZM/U+gA/hUdgOPxJJSGBIFYLuZmYu7uxZnY9WYnkk+pqSuKpVc9Oh9Ng8DDDrmesu/8A kFFFFYneFFFFABRUE88qT2tvb2c13c3UpihhhKBmIRnPLsqjCox5NWf7O8S/9CnqX/gRaf8Ax+rU JNXSMKmKo05cs5WZkeJv+RU1j/rxm/8AQDWrVTWND8Uahol/ZReFNQWS4tpIkL3NoACykDP77pzV 3+zvEv8A0Kepf+BFp/8AH6r2U7bGCxuH52+dbL9RtFO/s7xL/wBCnqX/AIEWn/x+q8j31pfw2epa Rd2Es8TyxGaSFw4QoG/1cjYx5i9cdal05JXaNYYuhOSjGSuTUUUVB0hRRRQAUVBd3P2WFXEMk7vL HDHFHt3O8jhFA3EAZZh1IFSzW2v2yB5/DF/EhdUDPdWagszBVHM/UsQAO5IFXGEpapGFTE0qT5Zy sx1ZWrf8hLQv+v5v/Seard/LqelJv1HQ7izQIX3XF/ZRjaGVSfmnHG50GfVlHcVzeo+JLaW+0hwL bEV2znGrWB48iVeouCB94ctgds5IBpUp9jCeNw7Wk1uvzOuorFHiOJrd7hYITAjqjyDV9P2qzAlQ T9owCQrEDvtPpWpYrrOp2cd5YeHbu7tZM7JoLyykRsEg4YT4OCCPwpeyn2L+vYf+dE1FQLLdR6hN YX2nXNhdRRJMY52ibcjlwpBjdh1jbqc8VPUNNOzOiE41I80XdBRRRSLCiiigAooooAKKKKACiitD QNAbxG4uLgFdHU/Q3Z9B/wBM/U/xdBx1uEHN2Rz4jEQoQ5pBoGgN4jcXFwCujqfobs+g/wCmfqf4 ug46+kIiRxrHGqqigBVUYAA7ChEWNFRFCoowqqMAD0FOrvhBRVkfK4jETrz55hRRRVGAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUjusaM7sFVRksTgAetQX19a6ZZS3l7OkFvEM s7ngeg9yTwAOSeK831rWrrxK+yVHt9KBylq33pvRpfb0Tp3OTgLE5qCuzow+GqYiXLD7y7rviubW i9ppMrwab0ku1O17j2jPVU/2+p/hwMMcWKKOCJYokVI0GFVRgAU+iuGc3N3Z9RhsLTw8bR37hRRR UHSFFFFABRRRQA7Tv+Rz8Mf9f0v/AKSXFeoXF9b2k9pDPJsku5TDANpO9wjSEcdPlRjz6euK8v07 /kc/DH/X9L/6SXFeieIdNm1XRJre1aNbtHjuLYykhPOidZYw+ATs3oobHOM4wea7qHwHzGa/7w/R Eep+KNJ0i8FndzTm6by9sMFpLO7bxKVwsasTxBKeOmznGRkTxTozRWsj3nkfarsWUaXMTwuJypcR sjgMjFRkBgM5XGdy55d9I1HURouoq19p91qWtvqEzQwr5lnGbKWKMMsiMEbYsKuGBG9mAPK4uat4 Uhd9Js5xd6lHe6nM+pzy4DSK1hPDl/LCqg2+WgKhe38RydjzTrEvreTUZrBZM3UMUc0ibT8qOXCn PTkxv+XuK4Xx9/yNegf9eN9/6HbVreHYNXi8X6y2qxSNssrWCK82gJdKs10VYEYG/Y8e8YXDZwAp UnJ8ff8AI16B/wBeN9/6HbVnV+BnXgf94h6mPRRRXnn1wUUUUAVrz/XaZ/2FbD/0qirv/HImbw3G tvJHHOdT08RvIhdVb7ZDglQQSM9sjPqK4C8/12mf9hWw/wDSqKu/h8YRSzEvpGpQ2AvWsf7QfyTE ZRMYANqyGTBlG0HZ3BOBkjtw/wAJ83nH8den6sp28OsRfEPS/wC1r6xus6VfeX9ks3t9v720zndK +e3TGMHrnjQ8G/8AIDuf+wrqX/pbNVdvGipBeXjaDqo0yzlnjnv82/losLskj7fN8wqCjHhNxA4B 4FaF94gS0vJLeDT76/8AIx9rezRXFqCARuBYMzbTu2Rh3xt+X5k3bnlHH2aXkngz4YrYTwQXR8jZ JPCZUX/iXT5yoZSeM/xD156V2mi6VNpovZru5juLy+uPtFw8URij3CNIwEQsxUbY0zljzk8AgCP/ AISfS1i1CZ59tvY2iX0k6/Oj2zqzLKhTO5TskGOvyHjBUk/4SSzhi1B7+OexbTrRL25SZQxSFlZt 37ssDgxyKQDnMZwCCpYA4rxX/wAlDu/+wVaf+jbmqVWfEcjTeOppXhkgd9Hs2aKQqWQmW5+U7SRk dOCR6E1WrgrfGz6vLf8AdY/P82FFFFZHcFFFFABRRRQAUUVoaBoDeI3FxcAro6n6G7PoP+mfqf4u g463CDm7I58RiIUIc0g0DQG8RuLi4BXR1P0N2fQf9M/U/wAXQcdfSERY0VEUKijCqowAPQUIixoq IoVFGFVRgAegrB13xJ/YOor58e+xj0q91CfYuZP3BhwFyQORI3B7gcjmu+EFFWR8riMROvPnmdBR XH6t42ltrFnstGvnu0u7JDbzoiO1vcTeWsoDSLt3bXVVYh1bG9VXJrUt/FFtc6oloLS7SCa4ltIL 1gnlTTx7/MjUBi4I8qXllCnYcE5XdRgblFcna+Pba/t9Mls9F1mZ9Tt3ubOIQIrSIgi3E7nAQfvc AsQG2HaTuj32LnxrpsNvHd28F3eWf2KPUZ7mFFC21q4YrK4dlYghJDtQM3yHK5IBAOkorD0LWrvV NW8QWlxYSW8enXq28MjFP3qmGN88Oxzl93QfK6D7wYDm/CXjW81ttEMmraHqUmoxB7my02IrNYZi MhaQ+c/yhgIzlV+aReQflIB6BRXJ2fjJl8K6VrF9pt3Ik2mQ39/cWsaiC1Rk3Mx3uCwGGO1N7AAZ HzLuuSeLrOLWLnT2s77ba3cVncXflDyY5JVjMQzuy24yqvyglTywVSGIB0FFYdv4otrnVEtBaXaQ TXEtpBesE8qaePf5kagMXBHlS8soU7DgnK7tygAooooAKKKKACiiigAooooAKKKKACs7WdbstCs/ tF25JY7YoYxmSZv7qjuf0HUkDmqfiHxPb6GqwIn2nUZV3RWytjjpuc/wrnv37AniuAdri7vHvr+f 7ReOMF8YVF/uIv8ACv6nqSTWVSqoep3YPAzxDvtHv/kS397e63eLeakVAjOYLVDmOD3/ANp8fxH3 AAycsoorilJyd2fT0qUKUeSCsgoooqTQKKKKACiiigAooooAdp3/ACOfhj/r+l/9JLivWK8du7G0 1CERXtrBcxBtwSaMOAfXB78mqX/CM6B/0A9N/wDASP8Awrop1lCNrHk4zLpYirzqVj2+ivn/AMQe H9FtvDeqTw6NpySx2kro62seVYISCOK0f+EZ0D/oB6b/AOAkf+FafWFbY4/7Ine3Mj2+vPfH3/I1 6B/1433/AKHbVyX/AAjOgf8AQD03/wABI/8ACrFno+mafKZbLTrS2kZdpeGBUJHpkDpwKiddSi1Y 6MPlc6VWM3JaF2iiiuY9oKKKKAK15/rtM/7Cth/6VRV2+geEYIBLdajHdm5Op3d0sL30rwYa5kki fyd5izgo4+XIbB4YZrjLm2gvIGguoI54XxujlQMpwc8g8daz/wDhGdA/6Aem/wDgJH/hW9KqoK1j y8bl8sRUU07aWOv/AOELnGlT3LJfSXf9q3V1Lp51KX7Pd273UjGMxeZ5XzRNkKdoL7Q/ylwdwx6n ourapJZ6XJqSapcLcI6TRxLbuIY4isu452fu1bcgc8sNnyjf5p/wjOgf9APTf/ASP/Cs2fw9og8T WMQ0fTxG1ncMyC2TBIeEAkY6jJ/M1qsQn0OGWUTir8yPSV8J6iunWdlG8BbQdPgt9LmmRQtzcIFY vIBuIhzHENuQQwdsbkhddjVdOl1W+8NXh0/b5F2ZbpJtheKMwyMFbBIOJlgOFJG5EYfdBHmH/CM6 B/0A9N/8BI/8KP8AhGdA/wCgHpv/AICR/wCFL6yuxX9jT/mR0Xiv/kod3/2CrT/0bc1SqrZ6ZYad v+w2Nta+Zjf5ESpux0zgc9TVquepLmlc9jC0XQoqm3e3+YUUUVB0BRRRQAUUVpeH/D7eInF1dKV0 dTwOhuz/APG//Qv9371wg5uyOfE4mGHhzS/4cTQPDzeI2Fzchk0cHgDg3Z/+N+/8X06+joixoqIo VFGFVRgAegpVVUUKqhVUYAAwAKWu+EFFWR8riMROvPnmFc/4j8Mf8JB53+mfZ/N0q903/Vb8faPK +fqPu+V0756jHPQUVRgc3rfhebU7u9u7e/jt550sBH5luZFRrW4ecEgOpYMX24yMYznnivpnge20 zxK+qxrpuDcT3KyDTUF2XlLFg9wSSUBkbAVVOAgLEBt3WUUAc/o/hj+yv7A/0zzf7I0ptN/1W3zd 3kfP1O3/AFHTn73XjnDl+GltJb6ZE8mm3L2umW+myy32lpcNsiDYeHc2InO9idwkHCcHad3eUUAZ em6VNp+razdtcxyQajcR3CRCIq0TCFImBbcQwIjUjgY569pNC0z+xPD2maT53nfYbSK283bt37EC 7sZOM4zjJrQooA8/1X4Ypqnh6y0iTUYGW20qPThNcWCzNGUQgSwBmxEzEjf94sqoAUKhq6C48Mfa P7S/0zb9t1W01L/VZ2eR9n+Trzu+z9eMb+hxz0FFAHJ6Z4HttM8Svqsa6bg3E9ysg01Bdl5SxYPc EklAZGwFVTgICxAbd1lFFABRRRQAUUUUAFFFFABRRRQAVyniPxd9imfTdJ2TagOJZG5jts/3v7ze i/icDGc7X/F8l+z2OhzFLcErNqCd/VYfX3foO2TyvOwwx28QiiUKg7e/cn1J9awq1uXSO56uBy51 bTqaR/MI4tjySvI808rb5ppDl5G9Sf0AHAHAAHFSUUVxt31Z9FGKiuWK0CiiikUFFFFABRRRQAUU UUAFFFFABRRRQBgeMXul8PSx20bMkx8q4ZV3MkTKQxA/IdOMk9qseG7q+vNGjm1BW80swV2TY0i5 4YjAxn6D171r0VV9LGfJ7/NcKKKKk0CiiigAooooAKKKKACuJ1q91iHxlAbaKTEYEVuixZWaN9hk 3NjjlfUY2g9+e2oqouxnUhzq17BRRRUmgUUUUAFFFFABRRWl4f8AD7eInF1dKV0dTwOhuz/8b/8A Qv8Ad+9cIObsjnxOJhh4c0v+HDw/4fbxE4urpSujqeB0N2f/AI3/AOhf7v3vR1VUUKqhVUYAAwAK FVUUKqhVUYAAwAKWu+EFFWR8riMROvPnmFFFFUYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABXMeL9G13XIYbTTL21t7Ig/ao5Q4ab0XK/wAPXI79DxkHp6KBptO6PN18E+JlUKt1 o4UDAAWTApf+EL8T/wDP3pH/AHzLXo9FZ+xh2Ov+0MT/AD/kecf8IX4n/wCfvSP++ZaP+EL8T/8A P3pH/fMtej0Uexh2D+0MT/P+R5x/whfif/n70j/vmWj/AIQvxP8A8/ekf98y16PRR7GHYP7QxP8A P+R5x/whfif/AJ+9I/75lo/4QvxP/wA/ekf98y16PRR7GHYP7QxP8/5HnH/CF+J/+fvSP++ZaP8A hC/E/wDz96R/3zLXo9FHsYdg/tDE/wA/5HnH/CF+J/8An70j/vmWj/hC/E//AD96R/3zLXo9FHsY dg/tDE/z/kecf8IX4n/5+9I/75lo/wCEL8T/APP3pH/fMtej0Uexh2D+0MT/AD/kecf8IX4n/wCf vSP++ZaP+EL8T/8AP3pH/fMtej0Uexh2D+0MT/P+R5x/whfif/n70j/vmWj/AIQvxP8A8/ekf98y 16PRR7GHYP7QxP8AP+R5x/whfif/AJ+9I/75lo/4QvxP/wA/ekf98y16PRR7GHYP7QxP8/5HnH/C F+J/+fvSP++ZaP8AhC/E/wDz96R/3zLXo9FHsYdg/tDE/wA/5HnH/CF+J/8An70j/vmWj/hC/E// AD96R/3zLXo9FHsYdg/tDE/z/kecf8IX4n/5+9I/75lo/wCEL8T/APP3pH/fMtej0Uexh2D+0MT/ AD/kecf8IX4n/wCfvSP++ZaP+EL8T/8AP3pH/fMtej0Uexh2D+0MT/P+R5x/whfif/n70j/vmWj/ AIQvxP8A8/ekf98y16PRR7GHYP7QxP8AP+R5x/whfif/AJ+9I/75lo/4QvxP/wA/ekf98y16PRR7 GHYP7QxP8/5HnH/CF+J/+fvSP++ZaP8AhC/E/wDz96R/3zLXo9FHsYdg/tDE/wA/5HBaf4F1Ca6X +3Lqzksl5aC1VwZT/dYt/D6gdenTIPeKqooVVCqowABgAUtFVGKjojCrWqVXzTd2FFFFUZBRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUV5vceNPH2l6daNc/Dye/uDETcy W93HGokAZyqRo0zFQq4DEgs3AUEhSAekUV5nc+LfiWdbutKtvAtojoks0N096Xt2jVCqrvwoLtKA QDtO0gFV5kG5HfeOZV19DptjDJHKqaQ8iApKpldcybZ8lRGI2JwjDc2EcqAwB2FFeZ6Trfxcmhuj qfhbRoXVHMOy4GWYQylRt80ggyrCpO5cBjwclk1LrX/H0WiyfZ/BcE+prFbhD/aMaxtI8JaVtpOQ scgCbd2WByG4zQB3FFcGvi3xpc2+tW0PgWSHVLO3he133qtbzSSAEr5jBAxQEk7cglGG4ZUtX1nx V4/0S3uLseDI9Tgj1O4RUtJv3jWYCiFgoLsXZmJOBwEOVGcgA9Eorj4tZ8bRatqEV14VgnsVinex mtr2NS7pJJ5aSBm+Xegj5AbaTk9SscY8TeNToz3B+Hsg1BbhUFodYt9rRFSTIJPUMACpA+8CCeQA DtKK5ODXvGA8QRWN54KjGnlwsmo2mrRyqoI+8EdUcgE4PAPBIDcZ6ygAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoorP1rULjS9MN1a6 dPqMwlijFtAQHYPIqMRnj5QxbkgfLyQOQAaFFed6R8StQuk3ax4ak0QyW8rQLePcKXnVgI4PmtwG eQElRH5jYU/LnirFv4+1qW/s7WTwLrMaTvaJJcbT5cJnSNjnKg4j3TBjjCmNQcb/AJQDvKK4ubx5 Kb9/7P0iTUtJFxBGupWXnTxsjpKZGURwtvKNGFwhYZkUFkOQKcnxE1hbF7tPAeuOv2Rp44BE4mLe dJGiMpTC8IjthmYCUEK6hmAB6BRXB3XxEvrDV2s7zwbrMNsLjyxqJTNqsQneN5pHx+7QRqJORyD2 XDsL8TYSmohtC1KJ4UmNhPMoW11RlYiFLeX/AJaPKuGUKpyCcbsZIB3lFcGfiVLCLgT+DvE8rxvE qfYtLmdZQ0YZ2UyJGQFfcnzAE/KQOSF0JfGrT2+mT6Ro13qCXV7b2l0EZd1gZAxkEyruKPFhd6sF A3j5uuADrKK4dvGviBJdSDeCb5ltrSa4t1jlYvOUZVCHMYQMSz8K7k+UxUOrRs8cXxHms7K1fxB4 Z1LT7u4srnUfs8AM4gt4U3EyuwQK56bBkgsgbaWAoA7yiuL0/wAdX2oBQvhXUoZGe1LQTfJLDFNc zQ+ZIhGVCrCHIG7746KC9dpQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2aBGHfCVwwAADfyyw+n6gEr2jEtxjWuFAf// 2P/gABBKRklGAAEBAQBgAGAAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRoc HCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIAWgB4AMBIgAC EQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAA AX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4 OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQAD AQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEG EkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpT VFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4 ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APM6KKK+ 6Pnhw606mjrTqTLjsLRRRSGLSikpRSGLSikpRQAtKOlJSjpSAdS0lLSABTqaKdQMWlpKWkIdSikp RSAdSikpRSAcKUUgpRQAtKKSlFIBss8NugeeVIlJwC7BRn8aRby1YsFuYSVTewDjhcZyfbBHNRX1 o12kQSXy2jfeD83PBGPlIPf1qsNHf7ELRrhfKVX27YtpDMrAk4OMfM2AAO3PHOE5VVK0VoWlC2rL 8d5azAmK5hcAgErIDgk4H5mni6t2kjjE8ReRdyKHGWHqB3FZjaI0sFzFPdFhOI1JAYkBWJ6szdc/ h6VLFpJiSGL7RmJGjdhtILMiqBznGPlHBB789MSp1usRuMO5ckv7OCQxy3cEbjqryAEfhmnx3trK 6JHcwu0gJRVkBLDnkevQ/lVK40aG5lklkkk3NMkq4dgF2hR0BxkgHnqM+1FtpBt18pbjdC0wmfcp Ls4IIO7PfaM8c84xkAHNW5tlYVqdt9S2NSsChcXtttBALeauATnA6+x/KlOp2ChS19bAMMqTKvIz jI59QfyqmuhQrbwRrPMrxhQ0qyMGOEZRt5+XlicDjtTbTQ3tJIWjuQFQAFArqCA7Njh/9rHzbulT zV9PdQ7U+5qxXEEwQxTRuHBKlWB3AHBI+hNMTULKRSyXluwXqVlU44J9fQE/gapwaQYZLaT7SS9u kaKNgCsFUryOufmfoccjg45SDQo4bcRGUycRAtIC3CdQMnhWBYY7bm6jgVzVdPdFaHc16Wkpa2Mh aWkpaQC0tJS0CAUopBSigBaKKKAFooopALSikpRQAUUUUCFFFAooAKBRQKAFooooAKKKKAOHooor uEOHWnU0da9sOj6wmi6C+geCfD2o28ulW8k1xd20W8zFfmyS6k8bTnHUnmuavXVK1+vnY2o03NM8 Worvta8JQav8UdV0rShDp1hb/v55JQY0t4wqmR8NjjcxwBxgjBC8jM1XwV5Vtp17oOpw6zY31wLN JVTyWW4J4jZGORkcgn8cDBJHE03a7tdX+/8AAp0pK/kcrSiu08RfDu60LR5NQju3uhasqXqvaSQL GzHaDGzgCVd3GV9VOMHjW1jwRDfeJPE0lzqmn6XBpX2VpDDZmKErIgztQMSCAOFGdzHHGan63S3T 0+fkv1Q/Yz2t/X9I82pRXYXfgJ5b3Q4tC1SLU4NY80W8zRNBtMZ/eFlbJwBznqcHA6Zk1HwRp1vo Wratpnia31KLTmjjdI4CrF2faerfd5BDDIb5gOmS/rNLTXfyfe3y17h7KRxlKOldN4a1bS9LsJgu hJq2vXMyxW6XcQlgSM46IOWkJ4/LB6g9jdaRouhza7rcmkW81/p9jaPNpsgzawXU+Q4C87lX5SAC RyQCONsVMRyS5XH089l+b3HGnzK9zyqlr1i00rQdUi07xZNo0UX/ABK7u9m0+BglvLJbMiD5ccBs kkdOBnPzbsi61GwuPC1h4vj8P6VDfW2oNYSWywf6LOpiZgzReoyMc9Rk54AlYq7so+Xz10/AbpW6 nnwp1d/4r1S2j8IadbzaDotrqmqRi6ZrSzEZgg3Dy9pBOS+CSc8DIK85ql8P7LTry6vRK2mvqwWN dPg1Qn7PIzNh9wH3mwQFHqc4OMilX/duo1/W39feL2fvcqZx1LXpep2MX9ueGYNY8LRaVqsuoRJI tqifY7mAyDOQCRvBIBHPB56qBZ1fw3pp8eQ6tDprpoUUNxc3MMaxKu60ZkdVTptLLHwevmHpzjP6 3HS66P8AD/MfsWeW0or0m90LTn+MN7FJaxQ6Pp8a3lzHFGoRI0hVj8mOQWIBABJ3H61z3jG0tn/s rW7G3ihtdUtFdkgQJGk6fJKqJ1ABA65ySSCaqGIU3FW3V/v1sKVNpN9jmaUV2OlaPb6n4Eso9kUd 1deIo7T7V5QLqjRDjPUgE5xmrUvw9sY1vyPFNmTpswW/LQOFhjJbBB53vwPkH8WVzkcjxNNO0g9l Jq6OGFKK7NPh+susyWUWtQfZm0v+04LuSIorxkgDeCfkHUk84AzjsM3XPDMOnaXbatpmqRanpk0h hMyxmJo5Rk7WQnIyBkH+WQS44inJpJ7+onTkldnP0or0PW/Bq6t4+1qG0VbHTbNYTKba2MhQtGu0 LEgyxJyTjgAEn3zYfh/cHX7vTJ7+K2SKwa/huJkKLJHkAbwcGPqc5GVweD1qI4qm1dvpcHRmmchT q7aPwHpkh0+dfFMBsdQbyrWQ2jiSWXft2iPPC/7RPBI45BqtpPgS5vZb/wC13LQW9nctaNLbWsly XlXqAiDIXHO446gd+D6zSs3f8GHsp9jk6WustfA0nna1FqmpQaedJaLznZd6Mj5O4EHOdoyBjJJA 4NbHh/wdpKeJtFlfU4tS029SaSANbOnnSRHBQqTwB97J4O0jHIyp4qnFN3v/AMNf02BUZt/16Hng pwrq9P8ACmj3884i8TK8YlEVuIrKSSac7NzN5IO4KORnkHB6cZ2LXwdpOnWHia21XUokntHgjFyL Z38mNirK4UHq/wB0gcrg8kHlSxNOOmt/R/11BUZM89pa7K58MS6pqWjWqSWNtE2jw3dxOkQiWKLn c7/Md7dMnjPHQAmq0/hCIvpc+natFfadfXS2huViKNFKTjDRk56cj+mQS1iKfVidKRy9OrrrnwVZ xLqkFt4ggudR06KSeW2W3YLsQ8/PnG7BGRzhuOxNY/hfS11nxNp9g4Vo5JQZFZiAyL8zDI5yVBA9 /Smq0HFyWyJ9nJNJ9TKpa737Ho+ueGL3UZZbTSrf+2W2Tm1XesPljZGqoOTyCQD2Zucc48vhOO01 57G/1e0trL7ObqO9zuE0X8JRQeWP93PY4zxmY4iLuno0U6TWxzdLXYXHgGSPWdJsoL/fFqPmbZJr Z4XTy+WzG3PTp0z7DmmyeGLPT9W0xbbVobuR7+KCW2urRonQkggtExyyEHnp1AzzwfWab2f5i9jN bnJUtdkvhCK9l1m/u79bO1tb+WD/AEaxeQArksdin5EAxjk46Z6Z5nVbGPTtTntIruG8jjb5Z4Gy rgjIP155HODkc1UK0Zuy3JlTlFXZTFKK6/8A4QT/AJcf7Xtv7e8nzv7N2/jt8zON23nH9Pmq7PHo +k/DyzmhFhNeX0UnzT2bPI7ZCsEfPyFM9ehIyOtZvEw0Udbu39eRfsZa30OEorsvB9lbXGm3L2kO mXet+btS01HlWiCFv3a8AuSOueAO2ebM+j2mp+MtI0+60ltKu5F3X0CAeRIFXcDHtPAYKQcHg+pB JHiIxk4tbf1sJUW4prqcLRXUL4m0qeKe0u/Ddglm0TLE1qu24Qj7hMhzk8AE4564PQy+E4tPsNPu da1WCGWD7RDaRCeISoSzBpTtwTuVBkH3I56U3VcYtuP/AARKmm7JnJ0ortdI0qHR/E3iK2uLOG5W wsZ5oEukWQEAqyE9slSOmOp6VBbXNr4psdUil0jTrK4s7N7qGeziMeNhUsrLnDZHAJ6c9c0vbq90 tNNfUfstN9f8jkaK7jwvYaZFpNquqQxl9auXtoneMOyRhGXfGcHY3mMoyfY44zUXhnTtMh03xHH4 gtsLbPDC7ooaSBi7KSpGehwTjOQOh6UpYhK+m1vnrb8wVFu2u/8Aw5xoorrE0Q6ZoXiq2voIWvLN rUJIAGKhn6qeoBBHp70XngS8s9KluDMzXkEXnXFuYHVETGTtlPyOwBGQPfGcc19Yp31f9WT/AFF7 Gfb+v6RydAruNbs9D0G60C6gnjuFEMLS25tM/aImLFpTv4yegU8jjkYGOc8SaaNI8R31igURxykx qpJARvmUZPOQCBRTrKb0W4p03Hcy6KKK2MwooooA4eirP2GX+8n5ml+wy/3k/M0/7Rwv86O/+ycb /wA+2Vx1r0C91zwPrdlpH9rJ4hS7sdOhsm+yCEIdg5I3EnqT6cY4riBZSA/eT8zS/Y5PVfzrKpjM JNp+0tbsa08txsVb2bO3/wCFhwP4s+13NlNdaS2nf2TIk0hNxLbZ5dmBA8wnk4wOcZz81Vr/AMXa Xp+n6VpvheyuFtbK+XUnl1EgySzrwoIQ4ChcDjGeOmCW5H7JJ6r+dH2ST1X86yVfApr3/wAS/wCz 8f8A8+2dr4t8bWGt2E8diNZEt8yPcQ3l87QW5GCVhQNhgW7uMDA2qM8Sa94303Vf+Ev8iC7X+2fs X2feijb5ON2/DHGccYz+FcP9lk9V/Ol+yv6rQq2BjZKe3n5p/ogeAxzvem/6/wCHO98K+IvOvfBO m6esS3+myXaub1/Lhk84khVYZOSMgcfeI4Nb/iHQ7Hw34B8SR2+lXempeyWxjN7dRO0rCXPloqM3 CKCQSSxyc525ryP7M/qtL9mf1Ws51sK5qUaqS36663/PyKWAxiVnSf8ASsdd4I8QeHfD0Nxc30ep rq7NtgurSOJ/IjwM7RJwGPzAkg8dMZNT23iTwzaXOqWPkaxeaLq8Km8lunT7Ws6szK6kHaRkg/N1 PJyBg8X9nf1WgW7+q1cq+DlJydTfz+77hLL8akl7NnfR+PdJsryx0+z0qV/DkFnLZSxzv/pEqTFW lbIOAcqMAe/K5G3I17X9Hfw7beH/AA/aXaWKXBu5p71gZpJcFRwp2gBePfjgYJbmfIb1FL5Leooj XwUWmp/i/v8AxB5fjmrezZu+M9fg8ReIWurKN4bCKGOC1heNUMUar93C8Y3FiOeh/Cm+G9T0ey+2 Wmuab9qsruMKZoVH2i3YZKtGTwOTyO/GcgEHE8lvUUvlN6iq+t4RQ9mp6E/2djebm9mzuJvGGj2k Wg6XpNvqB0rTtQS/lkvGDTMwYnaoB2gYJ6YyT25LNvfHcc+h69p8VvcebfX0strcNIA0NvK4d4++ AdoyoODuOenPFeW3qKXyz7Vn7bBb8/8AW5X1DHf8+2eg33xBtotT17VtGjuItR1FoEglmhjzbxIq h+SWyWIxtxjABzkYGTq3jGXxH4ZNnrTPNqcFyJra5WGMAxldrRnG3aOjZGckAHGAa5XYfal2miNb Axs1JXVteumgPAY5/YZ1Wi+JrLTtB06xmiuGlttcj1FyigqY1UAgZP3uOnT3pZvE1lJZ+L4RFPu1 m5jmtyVGFCzM5388HBHTPNcrijFN4jB3vz/1e4v7Px1rezZ6f4f12x1O7nk+yyywWHhNrW4hkOzz ShG4BgSQCDjPX2rmdc1zSX0C20HQbW6SySc3U014QZZJcFRwp2gBfz46YJPL0uaiNbCRlzc43gMa 1b2bPRP+E/sT4o1u5MN/HpmqxxK0kD+VcwtGgCspDY654zyMe6nPTxdaf2nq0zJfvBcaTLp1u08x mlYnGHkLNgZOSQvAzwDyTxm4UoYUKrgltPy+4HgMe/8Al2zq4fElnHZ+EoTHPu0e5kmuCFGGDSq4 2c8nA745rUsPG1ir6za3X9p29le30l7BcafL5dxGzN91vm2kFceuD68EcDvHvS+YPQ0SrYOW8/6v cSy/HL/l2/60Osk8UQXGm+JYpYJ0m1RrfyQZWmCCNs4d3YsTjHPr2AwKt6T4ws9MXwtm3nkbSmuf tAGAGEp4Kc8kA5wccjGe9cT5q+ho85fQ0Ovg2rc39Wt+QLL8cnf2b/p3O/0nxN4e0ux1DTbc65a2 086Sx3VsYluWUKAUduwDAkYP8R6c5fP4v0TUr3Wjf2+oLaavFbGUQbN8MkWPlXJwynGdxwe23vXn 3nL6GlE6+hqfa4O9+fX19P8AJD+oY61vZs7mLxjZRalpztZyzWa6Oml3sb/KzL/GUIP0xnGeenUN fxNo9kukWGkWl2NOtL9L+4kuSpmkcHGAAdoG3jtnjpgk8T9oT0aj7Qno1P22D/n/ABF9Qx//AD7Z 1tr4itIdb8SXrRzmPU7e6ihAUZUyNld3PA9cZ/Gq3g/UY9K8W6bdy7fLEux2d9oUOChYn0G7P4Vz n2lPRqX7Uno1U8TheVx51qrErLsddP2b0O8+06Po2m3vhXW7a/lMWpNKJoAsbKoQKrgMeScdDxtb IOQKfb+NLCPxWt8bCSGxgsjY2nlbXmgQfdcb8gt1H0PfnPA/a4/Rvyo+1x+jflUe2wjvzTvcr6hj ltTZ3974q0a6n0bzE1a6h06aQlrmYedKjgHf5isCGVhwB1AHzCpdS8ZaZc/2KkY1G6+wXsdw1xer F5ojXGUUr97OMkk5yBknt559sj9G/Kl+2R/3W/Kl7TB6e/sH1HH/APPtnfaX4q0m01HU7x/7WtZr m9e4jms3Qlo23YSSNyUOMk5wTk9RjnnvEOpQavr95f21v9nhmfcqcZ6AEnHckZPuTyetYX22P+6/ 5Uv22P8Auv8AkKqGIwkJcynqTLLsdJcrps9D/wCEy0f7d/wkH9nXP/CQ+Ts27/8ARvMxt39d33e3 Tt1+aue1DVYLvw5ounRpIJrHz/NZgNp3uGGOfTrnFc79ui/uv+Qpft0X91/yFKNfCRd1Pb/g/wCY Sy/HS0dNnT6NqGirp0+n61YSOjOJYru0CidG4BXLcFSO3Y545BGhd+MI4tT0V9KhmFnpK7YvtD5l lDABwx5ABAwMdO2OAOI+3xf3X/IUfb4v7r/kKbr4Ryu5/wBbAsuxyVlTZ2a3/hC2inubfS7+a7ki ZUtrp1NvGzcHBBDELk4J5+h5BD4xudJ0Ww0/Q5Gt2jV3upWhjzLIxz0IPCjjOcn0GBXG/b4v7r/k P8aPt8X91/yH+NL2+EfxTv66h/Z+OW1Nr0PQYvF2l3F+15qMN0JbrS2sbw28aZdyR+8ByASVHccY A5FZ76voemWN5FoMGom4vITBJPeOn7tCQWCqowdwBBJ5HGK47+0Iv7r/AJD/ABpf7Qi/uv8AkP8A Gkq2EW09AeX49/8ALtnb3Hji+s4rWz0KZrWytrdIsNBHmRx95yMHBJPTJ9e9GpeJdOu7bXhBbzRS aqts/l7FCxyIcvkg8g9c4BJJyB1riP7Qi/uv+Q/xo/tCL+6/5D/Gmq2DWqkv6d9fuD6hmD3pv+tD s08VJJ4KudEuoGa6Kxxw3C8lo1fcFck5wvIGOOcYHU3NX8Z2+p6dJJt1BNQnh8mWEXTrar2LqobJ JHG0/LzznHPA/wBow/3X/If40f2jD/df8h/jS9rg735ut/6+4PqGPtb2bO1mmsfFX9hWMEd5FqaJ FZOQqvEIlzlwB8xPO49AAD6ZrP8AFl+mp+KtRuotvlmXYpV9wYIAoYH0O3P41zX9ow/3X/If40f2 jD/df8h/jVRxGGjK6n/TFLLcbJWdNlyiqf8AaMP91/yH+NH9ow/3X/If41r9ew/86M/7Kxv/AD7Z coqn/aMP91/yH+NH9ow/3X/If40vruH/AJ0H9lY3/n2zMor1n/hSf/Uwf+SX/wBso/4Un/1MH/kl /wDbK+W5JH3P9o4b+b8H/keTV3t7Fok+m6QIotLe7S0ysRuIo0mk8u2yJWQoVxmcjewJZTzgha3P +FJ/9TB/5Jf/AGyj/hSf/Uwf+SX/ANspqEl0MqmNw02nz2t5M5i+svDFpfQnSrn7RaPaXg825ZPm YQNsJUncH3kgZVM4TaCQWa3eaJ4dTU9Xg0s2t5BHHcSKzXeTCq2wkjMWGHmfvN4P38BBnHJO5/wp P/qYP/JL/wC2VYT4R3kdjJYp4snW0kbc9utuRGx45K+ZgngfkKfK+xm8XQ0tVfbr9+xwWjX9p/Yr Wt+bOOI3tvE8v2SJp1t3EvmsrFCxI+XnkjjHpU1/YaJDHf8A2YQMVZtxku1DQjy0KeUEdw4aQupG ZCFChmQ5euv/AOFJ/wDUwf8Akl/9so/4Un/1MH/kl/8AbKXLLsW8ZhubmU7fJ/5HNzaZ4cmZmN3A pPhxLkbJ0ULeKFGwAfxHacqcklmPXGDR7Pwz5tkb+aCK2eEh5hLukYNbSGUshztZJdoj+VSeo39a 6T/hSf8A1MH/AJJf/bKP+FJ/9TB/5Jf/AGynyy7E/WsPy29q/uf+RgW+m6G0e8WWnT3aW1zNe2ov WMcBSNmi8krJmQNtBfDPj/Yqi+m6Xaa19jtV8+P7Be3HmTDLEGGVoTjAH+rETjAyGc55AC9qnwjv I7GSxTxZOtpI257dbciNjxyV8zBPA/IU3/hT1x5vm/8ACUS+Z5flb/spzs27NufM6bflx6cdKOV9 hLF0Nb1Pz/r+lucDb3emQeB54JY4n1C4nkWPEEbOgBgYMXJ3qMCQADg7m9K6Ky0rw1NqGnvNLpcl rLYWTXSyXKo0cpBWTbiWMDhMtnewZgdpya1v+FJ/9TB/5Jf/AGyj/hSf/Uwf+SX/ANspcsuw5YvD NO1Rq/k/8jA0qy8MweLNEinezmsLzS1a8M9x8kExjbdzkbWyo4PQtxg7cRQW3h2GO5kurXTmuhDl rcXjtFHII7lgI2WT5gfLt8/M3LkcEgDpP+FJ/wDUwf8Akl/9so/4Un/1MH/kl/8AbKfLLsJ4rDv/ AJev8TjdMg0O38S6pZ3csUunLJsilkYHdGlxGWIZe5iWTlcE5wOSAdNY/DN5p9s0hsxPJMktz8/l GOFooxNIoGPnWVJNkfPDEhCpFb//AApP/qYP/JL/AO2Uf8KT/wCpg/8AJL/7ZS5ZdhyxeGbv7R/c /wDI57T7Pw7dxTWb/YIZGjsfKkkuvLUuYHaYu5LFcEkfKMBxGCpGQeY10Wa65eLp8cUdoJMRJE5c KvpuJOT6kEqTnaSMV6R/wpP/AKmD/wAkv/tlH/Ck/wDqYP8AyS/+2UOMuxUMbhoy5vaN/eeTUV6z /wAKT/6mD/yS/wDtlH/Ck/8AqYP/ACS/+2UuSRt/aOG/m/B/5Hk1Fes/8KT/AOpg/wDJL/7ZR/wp P/qYP/JL/wC2Uckg/tHDfzfg/wDI8mor1n/hSf8A1MH/AJJf/bKP+FJ/9TB/5Jf/AGyjkkH9o4b+ b8H/AJHk1Fes/wDCk/8AqYP/ACS/+2Uf8KT/AOpg/wDJL/7ZRySD+0cN/N+D/wAjyaivWf8AhSf/ AFMH/kl/9so/4Un/ANTB/wCSX/2yjkkH9o4b+b8H/keTUV6z/wAKT/6mD/yS/wDtlH/Ck/8AqYP/ ACS/+2Uckg/tHDfzfg/8jyaivWf+FJ/9TB/5Jf8A2yj/AIUn/wBTB/5Jf/bKOSQf2jhv5vwf+Rw/ hFrVLrUGuIrWVxafuUuJIIwX82Po0ysgO3d1B4ziulEOjPHphabSfKi1GKS43LahyGl+ZCVYFkXe 4ZtoUhIyiBdzVp/8KT/6mD/yS/8AtlH/AApP/qYP/JL/AO2VSjLsc88VhpS5uf8ABnBa3qIu9N0p FjsFdoDJcfZ7WGNvMEsqjJRQR8mz5enQ471s20WlQ+MPFdpdx2cUTrc21oJgqpDI0yojDP3QuSSR yFViOldJ/wAKT/6mD/yS/wDtlPl+DMk8zzTeJGklkYs7vaZZieSSTJyaXLLsN4vC2sp236PvfsYe uf8ACM3Ntq2qWdppyndBJaQifY2CtuWjMSOMD5pc7QTnfypUbn6+PDt5r90bo2EcMkYla5tJ97Am +YMw2swZzC+4ggkYGAAMVrf8KT/6mD/yS/8AtlH/AApP/qYP/JL/AO2U+WXYhYjDK37x6evl/kY1 nZeD0uWjkSznja5Cl5rl0MY3WqsF2yY2jzLgg5biPO5gCTX0BdFsrLw9qEq2AvRqcIlZro7hHvly 7rvGzbiM/dA4Ulm3FV6H/hSf/Uwf+SX/ANso/wCFJ/8AUwf+SX/2yjll2H9Zw7VnVf4nK61baP8A Yr+W3j04XSQwApDdfLCfLgH7kAkSksZw2S2NuSQfvElhoI1vQY4BZyW82lpJeCS7IT7RsctubeNr ZC/JuUE4GVzmuq/4Un/1MH/kl/8AbKP+FJ/9TB/5Jf8A2ylyy7DWLw6VvaP8exz11a+E1u57Tbax 2o3P9rhuHeRR9u8vCjcVP7j5gNpJHzc1nagmlx6zoC3UFhBaiNPt8djN5qAefJuyysxJ2bf4iemM cCuy/wCFJ/8AUwf+SX/2yj/hSf8A1MH/AJJf/bKOWXYI4vDL/l4/xObnhSa5uhqKeGpJVYmwhtZo 4opDuwwLxMuECEkeYytlVAzlwXm18Jppc6QrazP5cxhuJbh1lP8Ax9lCV3AZ/dW/G3+PkfMK6H/h Sf8A1MH/AJJf/bKP+FJ/9TB/5Jf/AGynyy7C+tYa1vaW9E0c3Jo+jhbWGWOzt5pLJHhP2zBldrNn LS7nxGRL5e3OwEMeGHSxaLpNppms2BXS22QQyb3ug5Mv2KUMU+fa5EzYG0HBc+ild+T4MyTMGl8S M7BVUFrTJwAAB/rOgAAHsKZ/wpP/AKmD/wAkv/tlHLLsDxWHas6n4M56ex0K5nuzYWVgXtZ7pIo/ tTiGaNXhWN5XaT5QVeQhgyhmCjnoaMclto/i/W7JIrMWkbXixrdQRyhTGkvlAGQE53Be/wAxwDmu 3s/hHeadMZrHxZPaysu0vBblGI64yJOnA/KopfgzJPM803iRpJZGLO72mWYnkkkycmjll2BYvD6x dS6+f+RzFvZ+Gbm506UzQTXM8PmTwTy/ZoDIWj3BmX7gG64xjb/q0wrZBkZEnh90leeCwd4YLd0/ fMnmN9gdmUhWGf3yJnGG3MQTziun/wCFJ/8AUwf+SX/2yj/hSf8A1MH/AJJf/bKOWXYf1rDf8/H+ P+RyVza+H3tp5YltY90Cu4S4YmBzbRsgiBYl90xdGB37QP4OtXLrTvDt3qk6I0Qgmv2VXtH3S7jc 7fLjjXOY/I+cMEPzYAY/crof+FJ/9TB/5Jf/AGynxfBmSCZJofEjRyxsGR0tMMpHIIIk4NHLLsDx eH6VH+P+Rx95Y2dtfWGdEtZmmsDcy29rfExjy5nZ2D73zmKJlwGOCSRyMVydeyXXwo1G9d3u/F91 O7xiJmlgZiyBtwU5k6bgDj15qp/wpP8A6mD/AMkv/tlJwl2Lp4/DxXvT/M8mor1n/hSf/Uwf+SX/ ANso/wCFJ/8AUwf+SX/2ylySNf7Rw3834P8AyPWaKKK6D5YKKKgvL210+1kur25itreMZeWZwiqP cngUAT0Vyvhn4g6F4v1m/wBO0WWW4FkivJcbNsbZJGFzyenXGPTNdVQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAVyeoeK9Ss5deuE0m0k0vRHxdTNfMs7KII53KReUVJCyYALjJ HJHWusrzvXfAU2saj4h83Q/D9ymruBFqdy5N1ZqbeOLKp5JyVZGcASLknqvWgDsJvEOmW+qDTpJ5 BPvWNnEEhijdsbUeULsRzuXCswJ3pgfMuSHxDplxqh06OeQz72jVzBIIpHXO5ElK7HcbWyqsSNj5 HytjHvPDupTapeRxG0/s++1O11KWdpWEsTQeR+7WPaQ4b7OvzF1x5h+U7fmr6V4OuLDxKLuVY5Le K9ub6KdtRuXO6YyHattkRRkecy7wWyFJ2gvlQDQh8caH9nsmub2OOe5sob4pEksipDIDiUtsBEQK nLsFC8btu4ZuL4p0Z9Yj0oXn+mSyvDEnlOFldFZnCPja+zYwbBO1sK2GIB5uDwVqUXhXUNLae08+ 48L22jIwdtomjSdWY/LnZmVcHGeDwO9ewh1BvFmnadBBI1hp2sXt9JO9ncRFxMtyc75EWPCvOEAR pC4IcbQpFAHUX3iix0rUr+DUpI7S0s7e0me7kf5czyyRKDx8oDRj5icfNzgDNV5/GmnrdaPBBFdz f2jetZsDazI9uwiaT94hTKE4Thtvytv+6pNR6x4bvNQ1i6vIpIFjl/svaHYgj7NdvPJnjurAD1PX A5qObw7qS6+NRgNo6f26uoFHlZT5P2EWrdFPzhssB0IA+YZ4ALkPjXQbrTre/tLqe7guMmH7LZzT PIAFLMqIhYqu5VZsYVjtJDcVJc+MNAtLiOCTUo2d7eO7BiRpFEDlgJiyggRfKcyE7VyNxG4Zx28L aynhXw7pMN5GDYWUdrcrHdz26+YERRMHi2u4Ta/7olA+/JZSoqvB4K1KLwrqGltPaefceF7bRkYO 20TRpOrMflzszKuDjPB4HcA6ibxDplvqg06SeQT71jZxBIYo3bG1HlC7Ec7lwrMCd6YHzLmPw14g i8SaZLexW88Cx3c9tsmieMny5GQNh1U8gAkY+UkqeVNYd14OuJvFlxf7Y5bS6vbe+Zn1G5jETRLE Av2ZCI5TmFSHZhgsMqwQBtzw5p95pdjd214IPm1C7uIWhkLbo5ZnlXcCo2sN5BAyOM55wADYoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiuX8V+PtE8F32l2+tPLDH qHmhJ1TckZTZndjnneOQD0rfsNQstUs47zT7qG6tpBlJYXDqfxFAFmiiigArxL4q/CjxT4mun1LT ddm1KNSWTTbpxGI/aPGE/MA+pNe20UAfIvgf4a+Jdc1rU9MS8n0K8s40aVJldGcEkDpjI469K7r/ AIUR4w/6HX/x+b/Gvf8Aau7dgbsYzjnFLQB8/wD/AAojxh/0Ov8A4/N/jR/wojxh/wBDr/4/N/jX sl94x8O6bdva3WrW6XEZw8akuyH0YLnB9jVb/hYHhb/oLxf9+3/+Jp2YHiuj/BjxXqdlJcQ+MDEq XVxAVLy8tFM8bNwe5Qn8av8A/CiPGH/Q6/8Aj83+Neg+F/Gvh2y0meK51NI3bUb6UKY35R7qV1PT urA/jW1/wsDwrn/kMRD6o4/pRyvsB5J/wojxh/0Ov/j83+NH/CiPGH/Q6/8Aj83+Ne82V7a6jaR3 dlcxXFvIMpLE4ZW+hFT0gPn/AP4UR4w/6HX/AMfm/wAaP+FEeMP+h1/8fm/xr6AooA+f/wDhRHjD /odf/H5v8aP+FEeMP+h1/wDH5v8AGvoCigD5/wD+FEeMP+h1/wDH5v8AGj/hRHjD/odf/H5v8a+g KKAPn/8A4UR4w/6HX/x+b/Gj/hRHjD/odf8Ax+b/ABr6AooA+f8A/hRHjD/odf8Ax+b/ABo/4UR4 w/6HX/x+b/GvoCigD5//AOFEeMP+h1/8fm/xo/4UR4w/6HX/AMfm/wAa+gKKAPn/AP4UR4w/6HX/ AMfm/wAaP+FEeMP+h1/8fm/xr6AooA+f/wDhRHjD/odf/H5v8aP+FEeMP+h1/wDH5v8AGvoCigD5 /wD+FEeMP+h1/wDH5v8AGqKfBvxa+uy6V/wmLb47ZLkvvlwQzMuOv+wfzr6Orn4uPiHd5/i0qHH4 Sy5/mKAPH/8AhRHjD/odf/H5v8aP+FEeMP8Aodf/AB+b/GvoCigD5/8A+FEeMP8Aodf/AB+b/Gj/ AIUR4w/6HX/x+b/GvoCigD5x1r4N+LdF0LUNVk8YtIllbSXLIrygsEUsQOe+Kvf8KI8Yf9Dr/wCP zf417B47/wCSeeJf+wVdf+imroKAPn//AIUR4w/6HX/x+b/Gj/hRHjD/AKHX/wAfm/xr6AooA+f/ APhRHjD/AKHX/wAfm/xo/wCFEeMP+h1/8fm/xr6AooA+f/8AhRHjD/odf/H5v8aP+FEeMP8Aodf/ AB+b/GvoCqWpatYaPbpcajdx20TyLErSHALHoP5k+gBJ4BoA8M/4UR4w/wCh1/8AH5v8aP8AhRHj D/odf/H5v8a+gKKAPn//AIUR4w/6HX/x+b/Gj/hRHjD/AKHX/wAfm/xr6AooA+f/APhRHjD/AKHX /wAfm/xo/wCFEeMP+h1/8fm/xr6AooA+cdF+Dfi3WtC0/VY/GLRpe20dyqM8pKh1DAHntmr3/CiP GH/Q6/8Aj83+NeweBP8Aknnhr/sFWv8A6KWugoA+f/8AhRHjD/odf/H5v8aP+FEeMP8Aodf/AB+b /GvoCigD5/8A+FEeMP8Aodf/AB+b/Gj/AIUR4w/6HX/x+b/GvoCigD5//wCFEeMP+h1/8fm/xqjF 8G/Fsuu3elDxiwe2toLkvvlwRK0qgde3kn8xX0dXP2f/ACUPWf8AsFWH/o27oA8f/wCFEeMP+h1/ 8fm/xo/4UR4w/wCh1/8AH5v8a+gKKAPknx98M/Enh280ezm1CbXbm/MogihWR2TZszwc9dw/Ku/+ Fvwk8WaDeR6pqGuTaPGSGextXDtKPSTOUH5MfpXu21SwbA3AYBxzj/IFLQAUUUUAFFFFABVfUJnt 9Nupozh44Xdc+oBIqxVPVv8AkDX3/XvJ/wCgmgDx3SdW0q2sbCxk1K0S8eKPML3CiV3cA5IJyWYn Pqc+9blcJa6Zey6Zdy+defYpZLcXFmka4uIDbQrIVO0vkDP3Tk7CowxyLF9Hq8wu4rM6iNUdrtXO +RYfJKS+RsJxEGz5HK/N1z/HX0EKjUbNEHYPLHG0avIqtI21AxwWOCcD1OAT9AafXGXbS6l4u0+8 +zastjDLAIyUmjXJS5DMUGCBu8pSWA46/K2TUtINfa3AkvtRF07W4utltKvlyGeLcVaR2RgF83/V L5ZGc8bRVe28gseq+AXZda1+3U4iAtptg6b2Dhm+pCL+Vd3XAfD2NYdd12JSxVLezUF3LHA83qTk k+55rv68TE/xpepSCiiisBhRRRQAUUUUAFFFYniXXxolkqwqsuoXBKWsLdCe7N/sLnJ/AdSKaTk7 IDborgPDGvXWm36afq17LdW92/7m6mPzJMeqHsFY/d7A/KOCoHf1dSnKnLlkAUUUVmAUUUUAFFFF ABXPp/yUOb/sFR/+jXroK59P+Shzf9gqP/0a9AHQUUUUAFFFFAHP+O/+SeeJf+wVdf8Aopq6Cuf8 d/8AJPPEv/YKuv8A0U1dBQAUUUUAFFFFAEV1dQWVpLdXMqxQQoXkkc4CqBkk15je3kviDUG1G8iK w7THa20g/wBXGepYf327+gwOxJt/EjWLi2uBbTQn7HDb/aoId2Pt04OFjB5+62zC8ks6nHAz5o0d zb6NcaPeWkrO09jLGl+yAXBM0SSjCtIMF13seTmbkc5b0MHTUf3klcTPXfB+ttazR6BeyErg/YJm PLKBkxE92Ucj1Ueqkntq8P07Rfsy3by29ppsTiMpBYyfJE6Fm84NtTDnK/w/8s15PQer+GdSutR8 NWt9qKCKVlJLkbRIoJxJj+EMAGx2zWWLoezfMtEwTNmivP7jxzq183m6LaWcVkeYprze7yr2bYpG 0HqMknHUDpUH/CV+Lf72if8AgNL/APHKmOErSV1ELo9Horzj/hK/Fv8Ae0T/AMBpf/jlH/CV+Lf7 2if+A0v/AMcp/U6/8v5BdHT+BP8Aknnhr/sFWv8A6KWugryfw/rni3SvDel6d/xJ0+yWcUG14JGY bUC4JEmCeOo4roNL8a38d7Bb65bWqwzyLEl1aswCOxwodGzgEkDIY8kcY5EywtaMeZx0C53FFRzz xW1vJPPIscMSl3dzgKoGSSewAriJvH+oTPv0zQI5LY8pJe3pt2ceuxY3IH1wfUDpWUKc5u0VcZ3d FcB/wnXiD/oXdM/8G8n/AMj0f8J14g/6F3TP/BvJ/wDI9a/Va38oro7+ufs/+Sh6z/2CrD/0bd1g f8J14g/6F3TP/BvJ/wDI9Z8PibxBF4hvdW/sLTD9ptILbyv7Vk+Xynmbdn7PznzsYxxt754Pqtb+ ULo9Porg4/HmsI4a68OWxi/i+y6kZJPwV4kB/wC+hXZabqNrq2nw31nJ5kEoJU4wQQcEEHoQQQQe hBrOdKdP4lYZaooorMAooooAKKKKACo54VuLeWB87JEKNj0IxUlFAHlEej69pEEWnyaJeXf2dBGt zatEUlAGAwBcEZ7gjg+o5LvJ1r/oWdV/8g//AByvVaK7Fj6yVhWR5JbSaneRNLb+HtTkRZHiLL5P DoxRh/rOzKR+FTeTrX/Qs6r/AOQf/jldr4N/5Adz/wBhXUv/AEtmroKf9oVvILI5TwXol7p76hqO oQ/Zpr3y1W3LBmjRA2NxUkbiWbgEjGOetdXRRXJOTnJye7GFFFFSAUUUUAFFFFAFPVNTttH06a+u 2IiiHRRlmJ4CqO7E4AHqa8e1jX74a0t9dwxvNKokugGytnb+YqKmf4QN7uXPDeVJwBynsOq6ba6v ps1leKTDIOSDhkI5DKexBAIPqK8VGh6dql/qCaxFbanMwEUFw0G1XtwMBom9CxkJZehOMkKprtwV uZ2+LoJlTVtekF3q1m95pZFuwSPTZEP2i7BiR9qnzByxYqMIeR0J4r1bwjr8lyDpGoyl76BN0Uzd bmIcbv8AfHAb6g98DhLC1Oj215cX16J2lZZppjHs5WKOMnAz1MecD+9jtXd+EdAktgdX1GIrfTpt ihbrbRHnb/vHgt9AO2T0Y1RULz36CR1dFFFeUUFFFFABRRRQAVz44+Ibf7WlDP4Sn/E10Fc//wA1 D/7hX/tWgDoKKKKACiiigDn/AB3/AMk88S/9gq6/9FNXQVz/AI7/AOSeeJf+wVdf+imroKACiiig AopskiRRtJI6oiAszMcAAdSTWD5934k+W0eWz0g9blcrLdD0j7on+31P8OOGoAp+JreLxXG2iWcM cstvMkj3zrujspUOQR/ek/2R0B+YjIDcebYSXL2+pWcI1C0bZIrKG2nKsGQn+ElVYH/ZHQjj1a0t LextY7W1hSGCMbUjQYAFYviTwsmvNBPDdNZXkf7s3CIGLRE/MhB791P8J9QSD1YXEexlrsxNHK6J o/8AwkmoMJlzpNq+J89LiQf8s/dR/F6n5efmA7PxWxTwdrbISrLp85BHY+W1X7GxttNsYbK0iEVv CoRFHYe57nuSeSeaz/Fv/Ima7/2D7j/0W1Z1q0qs+ZjR5/ZgLZQKAABGoAH0qrrmo/2Tol3eholk jjxF5pwhkPyoGORgFioJJAGckgc1btf+POH/AK5r/Kqgu9J1HUEgS8tZ7yykaQRRzgvEwBQkqDng ORz6+tfQP4bIgxP+Emi/4R/zP7UtfN+3fYftfmJt278793+r3+T8/wDd3cYz8lQ3vix/+Ed0y5gv LGK9uo5HcvIqxF4kO5VZjtIMuxOCcqxKnjcOm/s20/tf+1fJ/wBN8j7N5u4/6vduxjOOvOcZot9N tLXULy/hh23N5s899xO/YMLwTgYHpWfJU7/139QJrW5hvbSG6t33wTxrJG2CNysMg4PPQ1U1vjSn I6iSIj/v4tW7e2htImjgTYjSPIRkn5nYsx59SxNU9c/5BUn+/H/6GtVUv7N37Ad/4/JHgTVgDw0Q U+4LAEfiCa5Gut+IH/Ii6p/uL/6GtclXDlu0vkORwlh4h1Oy07TNS1H+05re4gMk7Tra+WQLd5SY hHhwSU43cYJzziti88TXOnsbW605Tflo/Ljt5JJo2DiQgkrHvziGTgIf4ecElbtt4b0u1RY1glki SMxpDcXEk0aKV24COxUfKSvA6EjoTVW1h8NXdvKLa/iucSR7p11FpJUYkqgEu8uuSzAAEZ3MP4jn qUakVbmEVk8TXk19BBBpzCe4WJRDdSGFUJ+0Fm5j34Ig4yOQV4XnL5/Fc0dleXEGmec1jA8t2nnh cFXkjwhI+YboXJJ2nbggEnbWgum6NZ3ccgEUdxB5eC0x3AsZFQtk8ljLKMnJZmPU1S1XwnFqJaGN 4IbSVXE6GJ2dy7s7HPmBSQXZl3KwRiSPSm1VS0d2B0ddH8Oif7DvlzwupT4Hpkg/zJrnK6P4df8A IF1D/sJT/wBK5sx/hr1HE6+iiivHKCuXuPH+gwzvEj3tzsJUyW1lLJGSOuHC4b6gkVta27R6DqLo xVltZSCOoO014ppfiS2gs7m0kt5EOnW8OwLgm5zEh2xjjLZdV2+rpz8wFdOGoxqt8zsJs9N/4WJo v/PDVf8AwXTf/E0f8LE0X/nhqv8A4Lpv/ia4HT/Elle21k7lopbmKJyoRmjiaRQyo0gXaGO4YBIJ 3Lx8wzYtNc06+uxa29xvnMbSqpRl3Rggb1JGChLDDDhucE4OOxYGk9pCudt/wsTRf+eGq/8Agum/ +Jo/4WJov/PDVf8AwXTf/E15hH4xjOoGCUacq/bWsxEt/uuc+aYgfK2DgnDH5uF556Vej8U6dO9u 8EnmWk0EkwuArclWiAVVxliTKBgc7gVxuyAlg6L+2F2eoaT4w0fWLwWdvJcRXLAlI7m2khLgcnaW ADHvgHOOcVu145Z6naX+vaStpN5jW+qpFKQpARwXVlzjrwcj0IPRgT7HXFiKSpT5Yu6Gjn/Bv/IE uR3Gq6jn/wADJjXQVz/g/wD5BV7/ANhW/wD/AEqkroKwGFFFFABRRRQAUUUUAFQXt7badaPdXcyw wp1ZvfgAepJ4AHJNV9T1aDTVjQo891MSILWEAySkdcDoAMjLHAGeTVay0maa7TUtYdJrxOYYU5ht c/3M/ebHBc89cBQSKAIBZ3XiI+ZqUT22l9UsG4eces3ov/TP/vrOdof4k8PprOnoLcpDfW2WtJSO FOOUOP4GHBH0I5ArcqlquqW2jabNfXbERxjhVGWdjwFUdyTgAe9OLad1uBx3hjQLrUb9dQ1ayktY LR/3NrMPmeZTy59VU/d9T83QKT31cv4Y8UzarcS2OqQRWt/gywrExKSR+gJ6suQG9eCOuB1FaV5T lNupuCCivMPEc8us+J9VtLqacWmnyx28UEcrIhJhjlLsFI3H95jnpt4xk5y/7DsP+ecv/f8Ak/8A iq6KWBnUgpJrUVz2OivHP7DsP+ecv/f+T/4qj+w7D/nnL/3/AJP/AIqtP7Oqd0HMex0V45/Ydh/z zl/7/wAn/wAVTk0uO2Pm2M91aXK8xyxXD5U9sgnBHsQQe4pPLqndBzHsNc//AM1D/wC4V/7Vq74c 1KTWPDGk6pKqrJeWUNw6r0BdAxA/OqT/APJQ4f8AsFSf+jUrzxnQUUV5dqOq6jruo3r/ANpXlpaW 91NbQwWkpi/1TmNmZl+YkspPXAGOOpOtGjKrLliDZ6jRXjN9JdWP2Z21fW2ilnWGR/7TlHl7shTj POXKL7bs9AazP7dmaPUfL1LXWltWCQodUlHnO0rwouc/KTLGw7gAqSeSBu8DNOza/r5Cues+O/8A knniX/sFXX/opq6Cvnm31ibX530ttUllguERJIZtfnDzRyQrIxWIpll2uRzjODnFdFYG4vtOtbtd b1jbPEko2anORhgDwSQcc9wD7CiOCnLZr+vkFz2Sqt/qFrplqbm7l2R5CqACzOx6KqjlmPYDk15X NqOqeH7WfVLXVtQnNrG0zW93ctNHKqjJU7slcgdRgj36V6NpulOZ01TUpVutQZfkIGI7dT1WNT09 2PzN7DCjGtQlRdpAnchj0661uRbnWY/KtFIaHTcgjI6NMRwzeij5R/tHBG9RRWIwrzfxJq7eI7xr a1uJYtMtX+WWFyrTzL/GCP4UPT1YZ6AE6PjvxItpBPpcM7QKkBn1C4TOYYMH5VxzuYK3TkAE9Ste WWviKaTw3cKl7CtzbzWaltPCTeVHK0YZVChlJDGVFGCcKvUkM3dhaMb89TboJs9p8K+IG1a3e0vS q6nageaAMCVe0qj0OOR2OR0wTZ8WAnwbrgAyTp9xgD/rm1eUaNPqQvnvLS5u5GtQjW1xfW/kO7nd 5kTLsTMZAj529WJBJUbfXdJ1O18RaKl0kZ8uUNHLDIOUYEq6N9CCPQ9uKyxFD2crrZgmec2hzZwE dPLX+VcoGvorU2OkQXUjQQSC2ivLPY1lIImVNkzARuAdqY+YneW3soNd9L4L1/TmFtpTadeWSDEJ u7mSGRFHRTtjcNgcbuM+lR/8Iz4w/wCfHQ//AAZzf/I9ei8XRkleVvvFZnAWVpqU01rCt/qbWT3a iRhDPAQvkzbhmZ3kwT5YzwoONp3ZI0LyDXBLfW9nLL/o8c11aSFjmWSRWEcZLfKQrGT5TwAIPeuv /wCEZ8Yf8+Oh/wDgzm/+R6P+EZ8Yf8+Oh/8Agzm/+R6SxGHStzfmFmcBotpqUniKAPf6m+mrBI5D QzwIZQ8eAxmdpDxzjheCBnMgrpdc/wCQVJ/10j/9DWtr/hGfGH/Pjof/AIM5v/kermneDdWur2F9 cNhDawSLL5FpM8xmZTuUMzImFBAJABzjqBnKliaEaclF3b9QszY+IAJ8C6tgdIgT7AMCT+VclXpl 1awX1pNaXMSy288bRyxsOGUjBB+oNcPJ4F1mBzHZa1aSW44j+12jNKB6MyuAx98D+tcuCxEKV1Pq Noy64aLRdUPhjR5pZFN3bxWcMEK2jKYQZoGfzRvJYr5a5xswA2evHpX/AAhfiP8A6C2lf+Acn/xy j/hC/Ef/AEFtK/8AAOT/AOOV1zxdCe7YrM4VrK6g0+eydJ7idNUtpzcsmWuENxG287RjKAFCOyxg 4VSorqa0f+EL8R/9BbSv/AOT/wCOUf8ACF+I/wDoLaV/4Byf/HKccZQj1CzM6uj+HQ/4kl+ex1Kf B9eQKz18EeIHYLJrWnRofvNHZOWA9syYz9c/Q12Wk6XbaLpkNhaBvKjySznLOxJLMx7kkkn3NcuM xMKsVGA0i7RRRXnjKGtqz6BqKKCWa1lAA7naa8V07w7BcR2d+027e8Vxt2nlRFEAmc/34Inz/s7e hOfea5aX4faC8rPGL63ViT5VveypGv8AuqGwo9hxXThq0aTfMriaPNrLw3NZS6cUvYiLOCKAyC2A mZUXBQOGx5ZIyVYNySQQdpWtoGm6hDqNq9xFPDaWNk9nBHOsQO0mPafkd9zYjO4kqPu7VHzV6f8A 8K70X/nvqv8A4MZv/iqP+Fd6L/z31X/wYzf/ABVdX12krWixWPO49CvBm2lv4GsPtrXgjW2Ky584 zAb95GA2Afl5Hoeab/wjGLfSFW82z6XaeRDL5XVwYvm65AIiKsoPKuwyK9G/4V3ov/PfVf8AwYzf /FUf8K70X/nvqv8A4MZv/iqf12l/KwscFDo1t5+k6ddxxXlvPrBleOWIMrCSSSTaVOQQN2PwzXpP /CCeD/8AoVND/wDBdD/8TS6V4N0fSL5b2FLma4QERvc3Mk3l5GCVDEgHBIz1wSO5rfrixFVVZ3ir IaOb8D28FpoVzbW0McMEWp3yRxRqFVFFzIAABwAPSrniHxDBoFvCzQSXNzcOUgt4iAXIGSSScBQB yfp1JArn/DviWw0+11C2mt9VaRNVvsmDSbqZObmQ8OkZU/gayfFGtWur+KdFFtFfp5VrdlvtVhPb Zy0GMeai7uh6Zx361NGCnUUX1GzR/wCE91n/AKFu3/8ABl/9qqkvxUuWhspRolqEvVVrcnUSN4OM HmLgHco5xyyjqQDXrmY/Dk0rX6zS7CskhsJdoPls8v2gyYB5xJ5a7W/5456ORXqTwNNfCibnUXHx cuLWeWCTw8GljlWBliuJZCXZDIFG2A7jsGTjOB1xmrdr8SdUvF3ReGAo2hv313JEcEkdHhHPynjr jB6EZ88g8N302p2k1zBLHFJItxP5VxsaJm+2OyBkYMdrTouR97PpkDo7Sykt9cupgrfZzZW8MbvJ vJKNMSCSSxOGXk9c9TzUQwUG9VoFzqP+E91jv4bgx7al/wDa61bPxa2tweRo9nJ/aKnZcJcjEdmf WRhw2QQVVTlgR90ZI5WrHhC/1O21HX4rDSRer9qiZm+1JHtJhTjB+nWssXhYUoKUe40zudM0iLT2 kneR7m+mA8+6lxvfHQDHCqOcKOB9SSdGuf8A7U8St9zw1Avr5upKPy2o1H9o+Kf+hdsf/Bof/jVe cM3pJEijaSR1SNAWZmOAoHUk15L4g8VQaprdnNcGRbIsVsItp5yyoZ3Hbc0iIo5ID5wMtt6nxDB4 q17RZtOGjWNuZSp3/wBpkqcMDtYeVypxgjuCa83vNGvdfvNRee5udLmhQWaQhY5DG64dn5BKneVx tKk+UrBuVI7cHFOTlu1shMt3+t+VPctHaX0f9lyh21CPy9tuwRXLYLhmAV+QFOQSMHNer+G9eTXb As6CK9gPl3UAP3H9R6qeoPp7ggeR2GiG9uL+81W1nhe6ljk+zC8cxkeRErKyq2xxuDqcjkD0xXde CtOmu9Sk17c0Vp5Rt4AOPtIyCXP+yCML9WPQjO+NgnHnlv0EjhPFd9dWHxR1KaKZltUuS91F/C6G CxQsx/hCeYX3eikZAJNZunatrhiu2LZuJbvzniliMsltEYIX2CIMhYJ5mCV+bOPkJfjsdXsoW8a+ Io7u3idp5EdBIgO+B7eFG69VLRMD2O2obnS9PvUZLqwtZ0eQSsssKsGcLtDHI64AGfTit8PTk6Sa YMwZvEd5uSaJtO8j7ba2RTzC5kMoicvG/AcbZCAu0cKWz/DRqdvfXvii4hgRpYorKBth1Se0Clnm BIEYO4naOvTArTuNAgu9XGoTzyuV2Yi8uIDCMHUbwnmYDqGxuxn24qxeaNpeozCa+02zuZQu0PPA rkDrjJHTk/nW/JN7/wBfmI5S213WL3w8t1IVYQy6euYPlmneT7M7DqFAPmMPQ7sfKFO7b0vVb7Ud RjQGzNobKG8MiK+SJTLtVc44wq/MQDwflG75Nk2tu2/dBEd8iyvlB8zrjax9SNq4PbaPSonSy06K e78qGBQpaWRVC5GWbk9+WY/Vj601CSd2wOg8F2vipvAvh5rfWdGjgOmWxjSTSZXZV8pcAsLkAnHf Az6Cr2nxarF4+QareWd1IdLfY1raNAAPNTghpHyfxFang+1msfBOg2lzGY54NOt4pEYcqyxqCD+I qGTj4h2/+1pUuPwlj/xFfOFnQV5FYff1L/sK3/8A6VS167Xkdmpjn1SNwQ66rekqeo3XEjD81ZT+ Nd+XfxX6f5CYmpWX9oafLbCTypDh4pdu7y5FIZHx3wwU4PBxg8VUm8P2kn9lpGvlxaftREyTmNdp VM57PHE2eT8mOhNZV0t1bzzXazyyyPO0dteJeOYFkL7EimgztA3FYiVDHgsdjchx8T3k7P8AZdPZ VnXyrQzIc+fiPh8dgZHDAcqLeU88hfTc4N+8iTT0DRf7DsmtvtHn7vK+bZt+5DHF0yevl5/HHbNW 9Lsv7N0iysPM8z7NAkO/bjdtUDOO3SuRsdW1dvEdxbx3MAjuJWghWWOSQRFZbs7iDJySICCBtHzL jATDW7jVtUtrzU7pZrOaKx09Jp1VmZHKSXAZUGfkZtmCSW2FQMPjIUKkEk0gNvxF/wAixq3/AF5z f+gGut0q1s7547OTXfENlqGzJs7m62ORjkrwQ6+6kiuS8Rf8izqo7m0lUD1JQgCu8+xwwxwaJr0K 3djIQLK5m5ZHA4jZuocfwuOTjGdwy3BmXxRHEs/8Ir/1Htc/8DP/AK1H/CKIeH1zXHXuPtzL+q4P 60fZNb0XmxnbVrMf8ut3JidB6JKeH+knPq9XtN12x1OV7eN3hvIxmS0uFMcyD1KnqP8AaGVPYmvN KOU8TfDuG+sXuLK71Ca+jC/u7m8aVbmMMGaFt5ICtjH488E1ys2nWmsPDe75o2XYGVcKSY5VkCuC M5VkIwem5x1Nez1xXijw1ei/Op6HbrNJckJc2xcIpbosoJ6Y4DdyACORhu3CYhQfLPZiaMCC0udY 1BdKsXMcjLvuLgDP2eP1/wB44IUfU8hTWzYyeLfB1lDZT6Na63pduoRJtLPk3CqO7QucOf8AdbJr pvD+hxaFpogV/NuJG8y4nIwZZCOTjsOAAOwAFatZYmu6079OgJWMvQtfsvENm9xZC4Tyn8qaK5t3 hkifAJVlYDnBH51qVFc28V3azW0ylopkaNwGKkqRg8jkcdxXIf8ACKeINDy3hjxHI8I6afrObiL6 LKP3iD8W+lc4ztKKx7XV7m00CXUvEltBpbW4Yz7J/OjCj+MMADg+mMir2n6lY6taLd6deW93bt0l gkDqfxFAFqimTTRW8LzTSJHFGpZ3dgFUDqST0FcDrHxc0WyZotKt59VlH/LSMiODP++3J+qqw96m c4wV5OxpTpTqvlgrvyPQaK8Nvvip4quywt/sFhGfu+XCZXX/AIEx2n/vmsO48W+KbsYn8Sagf+uZ SH/0Wq1ySzChHZ3PRhk2LlukvVn0dRXzM2sa2/3/ABDrRx6ajMv8mFPXXtfRgy+ItYyOmb12H5Ek Vn/adHs/6+Zr/YWJ7r73/kfS1FfPdt498X2jqV16SZR/yzubeJ1P4hQ3610mm/GHU4WC6tpFvcp3 ksXMbD6I5IP/AH2K2hjqEutvU56mU4umr8t/Q9gorn/D3jXQvEpEVjd7bvbua0nHlygd/lP3gPVc j3roK6k01dHnSi4uzVmFFFFMRDd3KWdlPdSAlIY2kYDrgDP9K8wj1vxJqcMd6fEFzZeegkFva29u Y4wRnAMkbMcepPPoK9F17/kXtT/69Jf/AEA14PbNLFpeq6lHc3X2uz8pbSL7Q5jZvs0JWPys7W3s xGMbiW4IOCO3BwhJtzVxM7X7Z4j/AOht1P8A8B7P/wCMUfbPEf8A0Nup/wDgPZ//ABiuSg8Q30X9 rSeTA1rp0VxcuGdzI5Wa5UICScA+Upz0GCAuCNssGs62Z47C5t4Le7nlRIpZY1woKSuSYkmckfuS Ad65LdPlOe9U8O7e6LU6j7Z4j/6G3U//AAHs/wD4xR9s8R/9Dbqf/gPZ/wDxiuS/tTVINWv3e7s5 lEVpAiRKxjSR7iSHf97qCCWXrwF3fLua3bavqkuvJpJFmzRNL9onCMoYKIHBRNxwSJ9uCx5G7PG0 ipUP5Q1Ot0rX9asNasIb3VZtStrycW7LcQxKyFgcMpjRe4GQQeCa9Irwi21nUJtZ0UHT3mltLuMX cUICs8+4gLEXYLjCs/zEHa8R/ir1f/hIdU/6EzXP+/1l/wDJFebi4wjU9xWQ0Hg//kF3w7jVb/P/ AIEyGsHx3/yNGgf9et5/6Fb1s+CZXn0i9lkt5Ld31O8ZoZSpZD5zcHaSuR7Ej3qfxN4cOvRW0sFw ttfWjM0MrJvUhhhkZcjIOAeCCCo+hyoTUKik+g2ea61fXVl5HkvFbwNuMt3LA8yRYxgMqspUEFiX J2rs56iq48TWtrZs986l42AL24ykqGMyecnP3Niue/KOoLkDPQ3vgPxXd7Gi1ixtJEyN8AY5BxkF XVlPQc4yOxAJzVi+FusI8bvNo8xWOVH81HYTGRizM4xgnLSYxgASuAAGxXpyxtPm91k2MDV/FL2d 1FDZWktyTP5LYRdr4lgRirF1HBlKdD84OcBTma58TbdOW9hsrpYHkgMUrxb1mieVFLKEJYHa+QrA Mc/dOCBpzfCjXpra0iGp2Mb2se1JlDF2bzI5TI2VILl4lJJHOWz1p8fwt8RRwR251eze3haI28LF wsKxurqowo3D5FGW3NgHBGSTP12N3qFhLC/W/SX9zLBLDJ5c0Mu3dG20MASpKnKsp4J6+uQJfDlt aSa5q0l5HLal7uKKDU7aTZJDIYo8Ix/utxgNlSeCMlc3LbwH4ktri7lS90rddTCWTKyHBCKnHTjC D8c11+h+GYNK0m5s7pkvJL1zJds0eEkJULgKScKFUDGT09SayxeJhUpqMXrcaQz7brWjcajbnU7M f8vlnH++Qf7cI+99Y8k/3BWvYajZ6pai5sbmK4hJxujbOCOoPoR3B5FZlnPNo13Fpl9K8lrKdtld yHJJ7RSH+8B91j94cH5hlpr/AMPWl3dG9t3lsNRIx9rtCFdsdA4IKyD2YHHbFecM1q5HxfoMkjf2 3p0TPdRJtuYEGTcRD0H99eSPUZX0xe/tbVNH+XW7T7RbD/mIWMbFQPWSLlk+q7h3O2tq0u7a+tY7 m0uIriCQZSWJwysPYiqhNwkpR3A8z0iwHiu8FvBITpiBXu54zjeCAREp9WBySOQp7Fga9QjjSGJI okVI0AVVUYCgdAB2FV7CGGCB1hshZqZpGMYVRuJc5f5SR833vX5uQDkC1WletKtLmkJKxxni/VNA e8TT77QP7buoV3lBHGfs4bplnIwSB0GTjGcAiua83w1/0Tn9bf8A+Lqprmqmz8e6/ax2N1eTzXSy KsBjG1UtbUHJd1HWQdPelTW9PfLG5ijjEYffLIqf38gqTuUr5b5BAxtPdWx20MJSnBOTdxNlrzfD X/ROf1t//i6PN8Nf9E5/W3/+LpqX9nJfSWKXcDXca7ngWQGRRxyV6gcj8xVFvEuj+bZJHqNrN9sn NvE0UyMN4Xdg8/7o47uo71s8DRW8n94XZoeb4a/6Jz+tv/8AF1PZ6j4W0+7ju5PAZtBEd/2lYoJT Dj+PAYtx6qCfQVTj1TT5XmSO/tXeCRYpVWZSY3ZtoVueCTwAe/FOS+spoPNS6t3iLIm9ZAVy4XaM +pDLj13D1FH1Ci9mwuesRSxzRJLE6vG6hldTkMDyCDWFN/yUOz/7BU//AKNhpfApJ+H3hokkk6Va 5J/65LSTf8lDs/8AsFT/APo2GvGKOgrD1Xwfoms3hu7u2mFwwAaS2upbdnxwNxjZd2Bxzmtyimm1 qgOK/wCFTeDP7Q/tD+zbr7b/AM/P9pXXmdNv3vMz04+lSj4YeFF2bbS+GyRpUxqt38rtncw/e8E7 mye+4+tdhRT5pdwOHl+EPgicuZtJnkMilXL6jcncC+8g5k5G/wCb689amHwr8ICFoRYXgiaIQMg1 S6wYxkBCPM+6MnjpyfWuyopcz7gc5Z+BfD1jdxXUdrcSyxMHT7VfT3Cqw6ELI7DI7HGRW7d2kF9a yWtzEssMg2sjd/8AD69qmoobb3AxbG7n067j0nUpWk35Fndv/wAtwATsb/poAM/7QGR0YC7qWkWG rxIl7biQxndHICVkiPqjrhlPuCKlvrG31KzktblN0T+hIKkchlI5DA4II5BGaoadfXFvdjSdTfdc 7S1vc4AF0g68DgOP4h36jjIVAVtuu6L9xjrViP4XKpdxj2PCSfQ7T7sau2msW+s2tyumXSJdxqVa O4ibfA5Hy+ZESrYzzjIyOh71p1VvoYZLK682xW8Dwsj2+1CZ1wf3fzkKc5IwxA55oAtUUUUAFFFF AAQCMEZFcrf/AA+0O5u3vrBZ9G1FuTd6VL5Dt/vKPlf/AIEprqqKAPnvxZr+qandy6NealJeWumz Pbs7II/tMiMQXdV44IwB0+XPU8c/XofxC8CXdrqVxrmk273FrcMZbqCIbnic/edVHLKepA5Byeh4 86jkSVA8bqynupzXz2OjUVVue3Q+0ymdB4dRpb9e9zW0PR/7Ymukzc/uIPO2Wtv50j/Oq4C7l/v5 69Aamu/DlzFdmKFsIEV2N4UtWiJJAWQO2FY7SwXcSVwfXGfaXn2W2vofL3faoBDnONuJEfPv9zH4 1oHW7e5SWO+s5ZEn8qSYwziNnljDKHyVb7wclsgktlsjOKwj7NxSe51z9sptx27aeXp5jLnw5f29 jBdeU2HieSRHAR0KSOjqFJyxUJubA+UHnA5qWz8K6hcztHIYIQsUjsWuI8xsqMwRxu+RjtIw2CAG OMK2JL3xXHcK13cWUcd4sNxH54mITEzyF8qc8ASkLgjB5JYYAcniq2+13bnT5g93I8l/GZ9rb3jk T5AUzGP3znDbj93nrnRQpb9NP62MXUxHw2XNr2/z/rqZUmk3kVkLt41Ee0OVEil1U4wzIDuVTkYJ AB3L6jNKtSfVoptFjsPs0u9MbS85eOP1MakZQt/F8xUkk7eF25dYSUV8J103Np86DkOjo7pIjBkk RirIw6EEcg+4r3P4c+KLjxJoUq32GvrGQQyyAY80bQVfHYkHB9wTwDivE9PsrvVr8WGm2z3d2efL j/hHqx6KPc1714K8LJ4U0P7MzrLeTv511IvQvgDC/wCyAAB+J716mWxqJtv4T5/PZ0GlFfH+nmdH RRRXrnzZBe2wvbC5tS20TxNGWHbIIz+teQQ+HrnTLmJrjwnPJqUCCM3lvapJvwu3csgOcEeuDjgg V7NXNXPj7w7a3MkBurmZo2Ks1rYXE6AjqN8aMpI+tb0Ks6b9xXEzhora6gd3h8L6nG7/AH2SzALf Mzc4PPLMfqxPeq6aOsdjJYp4MvFtJG3PAunoI2PHJXoTwPyFd5/wsXw5/wA9NT/8E95/8ao/4WL4 c/56an/4J7z/AONV0/W6/wDL+AWRw39mN/0KF9/qPs3/AB4r/qf+efX7n+z0p9vYzWixLbeE9RhW JWWMRWSqEDEFgMHgEgE+pFdt/wALF8Of89NT/wDBPef/ABqj/hYvhz/npqf/AIJ7z/41S+t1/wCX 8AsjlNA8O6hda9bTf2bfWsSXwvrm4vFVNxC7VVVB54CL0xhckk9fVaxNJ8W6LrV19ls7qQXGCwiu LaW3dgOpUSKpbHtmtuuWtUlUleW4zn/CP/HjqX/YVvP/AEc1Z/jfVr22udN0qzuJLX7Ys0ss8WN4 WPYNqkg4yZBz1wD61X8P3PiONNUWw0rSp7carebZJ9Tkic/vm6qIGA/M1zPxFTxBqF1aQXVla2d0 dNvvshsNSkdmkzARljHHt5C9yDk546lBJ1Emrgx/2a6/6Det/wDgyl/+Ko+zXX/Qb1v/AMGUv/xV ck1p4zjgvlgvJQgnkWzUiFnWNUm2ZZt24MfIBLHd97OPvF5Hi86ibSK4n2rFKBcSpD5eSbkRsxC5 LcW5wowBncOa9jlpf8+/wRB1X2a6/wCg3rf/AIMpf/iqPs11/wBBvW//AAZS/wDxVcuLXxENXsP7 MW+sdN8zddR31xHcM2GUnks7KCu4Dax+YfdXljY0/TdZj1bRb6/ury4f7FKl2D9nCQyMIzt+VQSp Knpk5VecE5ahT29n+AHQfZrocjW9bz/2EZT/AOzV2XgjVby/tdQtL2ZriSxuBEk7gb3Qxq43Y4JG 4jPcAd8mvGLLRvGFvZ+St232iSKFzJNdOURljfIJLSNv8xlJCqEZY8Z+YrXq/wAOXaR9edo2iZrq ImNyMqfIj4OCRkexIrjxcYeyTUOV3/zGjs7u0gv7SS1uohJDIMMp/wAex7gjkGsywu59PvE0nUpT IzZ+x3bf8vCgZ2t2EgGc/wB4DcP4guzVa/sLfUrN7W5UmNsEFThlYchlI5DA4II5BFeaUWayJfD1 oNQ+32Ukun3TOHme1IVZ/USIQVYkcbiNw7EUadf3EN3/AGVqbA3YBaCfGFukHfHQOONy/iODgXdR 1C20rT5r68k8uCFdzNjJ9AAO5JwAO5IFADrN0kgYx3n2tRLIDJlTtIdgU+UAfIQU9fl5JOTViud8 NeKRrjzW11a/Yr6MeYIC+7dETwwPcjIDDsfYgnoqcouLswPFtdttQ/4WRrd/YQ2s3lTmF0nnaL79 tZkEEI2f9WfTrWbH4Vkj1m1upHgnhjlSeTeuCZM3TsVXBwA9wpXkkBeuQCfQte8Lar/bd3qWkJbX CXpR54Z5jEUkVFTcpCsCCqKMcYI754zf+Ef8Wf8AQK0//wAGB/8AjdepQrUFTXM9US0zipvCMtw1 5A7qIZmunS4a6mcqZhIOIMiNSPNI3ZOQDwC2V0JLHVLq/sb6a206KWC5VnWOZmLRiOVCfMKDJHm5 C7QOD83zcdL/AMI/4s/6BWn/APgwP/xuj/hH/Fn/AECtP/8ABgf/AI3Wyr4ZbS/r7gszim8L3lzZ 2FndLZtBYRRWy5YuLmNZYXYupUBSVg+78wJfGeMnTn07zvE8Tqsv2byxcXC4xG0yHbETxhjgsT1I MMR4wM9F/wAI/wCLP+gVp/8A4MD/APG6UeGvFdwfKNpp1qH4M5vGk8v3ChBuPtkfUUfWMMvtfn0C zL3gvwX4VuvAvh64uPDWjTTy6ZbPJJJYRMzsYlJJJXJJPOauWmhaRonxCshpWlWNh52lXXmfZbdI t2JbfGdoGeprpdL0+HSdJs9Nt93kWkCQR7uu1FCjP4Cub1rXNJ0f4g6Y2p6pZWS/2VdDNzcJH1lg x94jrtbH+6fSvEKOl1LULfSdMudQumKwW8ZkcqMnAHQDua4xvHeuMxMPhyxEZ+752qMr49wsLAH6 MfrTfG3jDwxf+D9QtbPxHpFxcSqqxxQ30bu53rwAGya8+m8UalZ+Jv7Le0gu45b3yIzETE8SBYWL EEt5hAnGQMYCM3TO3swtKnNN1BM9B/4TrxB/0Lumf+DeT/5Ho/4TrxB/0Lumf+DeT/5HrzaHx5cP b+dNplrCjRxujPfHaNxt/vkx/KALlSTz91vrT5vGcyae2o4s4glslwmnSljPcK0SyFkcfwjcwzsI /dtkqM7er2GF8xXZ6N/wnXiD/oXdM/8ABvJ/8j0f8J14g/6F3TP/AAbyf/I9eczeKtYutBvri10y C1mh09rpmku9xjyZVVkxGVkGItwOQCGHbmpdR8T39rqlosS2f2BorWW4uMh4kEruGPml0AXah2na dxwOCQCfV8NvqF2eq6D4xl1LU003UtOSyuZUZ4DDc+fHJtxkZKIQ2DnpjAPNdXXi/gnWJtX8X6Ob q1a0uI3mJhkRkYK0BYHawBwDuTd0YxsRjoPaK8/EQjCdobDQVV1HT4NTtDBPuGGDpIhw8bjoynsR /wDryOKtUViMytM1Cf7Q2l6ntXUI13K6jCXMYwPMQduSAy/wk+hUnk/E2u3GrXzWGmXk1raWj/vL mBsNLOv8IPdUPXszDB4BBs+P9Vt/Kj0yOXybmPF1LeCTYbKMZ+YN2ZgGA7Y3E8cHzmPXri18NyO0 Fvps8ElqgS4U7YopjH8zKSpwu91JyAWiY8cqO3CUIv36mwmz2Lwxr/8AbVk8dwEj1G2wtzEvTJ6O v+y2CR6YI6g1uV4joes3rak99Y3dlfT2aqVubQFIZ1Ytvt2+Z+RtVs54LoccfN7DpWqW2s6bDfWj ExSA/KwwyMDhlYdiCCCPassRR9nK62ewJl2iiiucYUUUUAFc3rngPw74gla4vNPVLtutzbsYpCfU lcbv+BZrpKKTSasxxk4u8XZnlF78GXBJ03xA4UdEvLYOT/wJCuP++TXEa34W1bQtXg024n0+WSUb jIjTBYl7M37sj8ASfbHNfR1Fc0sHQl9k7oZni4Kym/nr+Z5LonhfwXp9jBf6jFN4immLoJF0qa6i iKkBlEaI2znHL8nBwccUmg+FfCWqeD9Os7vRbnSdUtdNje6vf7Lls3R1RRIWleMI5zkkEtnk4OM1 sJpl9qMV79jtvO8vVbzf/wATu50/GXGP9Qp39D97p26msrT7uWTR5JZdPnt49W8O3N9bs/iC6vsI FiO1o5QFVv3y8gnoR0NYOCScFsczqzlP2jevc4uLw6k2vw6cmvQG0uCFgvo7CWQEnoHTI2k+uSvu Olej6d8HtGgIbU7+91A45jD+RH+SfN/49Xc6T/yBrH/r3j/9BFXK6YYWlDaKNamPxNRWlNlTTdKs NHtBa6bZwWkAOdkKBQT6nHU+9W6KK6DkCiiigCjrUjxaFqEkbFXS2kZWHUEKea8v0lVTRrFVACi3 jAA7fKK9P1wFvD+pKoJJtZQAO/yGvMdKIOj2RByDbx/+givTy3eRMiK/1U2V3b2sdjdXc88byBYD GNqoVBJLuo6uvSmW+v2F1qK2MUjea8SyoWQqGyXBTno48t8qcHg8fK2Gajbah/a9nf2ENrN5UE0L pPO0X32jIIIRs/6s+nWqUPhmSK4uJftKiVliljmC8rOJppXO3sh84rgNkqWUnnJ9BufNpsIsW3iW K9gS4tNOvri3McbyyRqh8rciyYK7tzEK6nCBuuBk8Vt1ykeganDYWFvHFYrc29pFbrqEczxyw7VA IwF/eoGy21iqtwCvGT1dVTcn8QEOSuuaEwOCNSjwR7hgf0JH416xXkN5aW1/qGjWt3bxXFvLqMSy QzIHRxzwQeCK77/hBPB//QqaH/4Lof8A4mvIzD+N8ikHhH/jy1Idxqt5/wCjmqp4y0K+1GXT9R06 Jbi4shLG1uXCGRJNudpPGQUXrgYzzU3gq2t7LT9StrWCKC3i1O5WOKJAqoA/AAHAFbt9f2emWj3d 9cxW1un3pJXCqM9OTXHCThJSW6Gebf2b4n/6Fm4/8C7f/wCLo/s3xP8A9Czcf+Bdv/8AF11n/CwP C3/QXi/79v8A/E0f8LA8Lf8AQXi/79v/APE12fXcR/SFZHJ/2b4n/wChZuP/AALt/wD4uj+zfE// AELNx/4F2/8A8XXWf8LA8Lf9BeL/AL9v/wDE0f8ACwPC3/QXi/79v/8AE0fXcR/SCyOT/s3xP/0L Nx/4F2//AMXXWeDdEu9JtL2e/VI7m+nEzQq27ylCKgUnoT8uTjjnHOMk/wCFgeFv+gvF/wB+3/8A ia3bG/tNTtEu7G5iubeTO2WJwynHB5HvWNbEVai5Z7AkWKKKK5xlTUtPg1K0MM5ZNrCSOVDh4nHR 1PYj8iMg5BIry688Svr+pWttfXMBSDcbZYshbthuAnwemQGKLk8B2BYDI9F8UaZc6x4du7G0mEc0 gHBOFlAIJjY9QrAFSR2PfofEZbbU7m4uddiRYvstyu2ze2Y3KpBuSSMYfbuO642gqc+YORxt7MHB OXNu10/UTNv+3bV76J7K4nhvba4ZIbl7SUQiUMUKFyoUhjlCM8k4HOK9W0HW4dd00XKL5UyHy7iA nJhkHVT6jkEHuCD3rx7StFllika7u7wQjULidbNlRY8i5d0bOzfjIVx82D9Diu58E2U9zrFzrETG Kx8s23H/AC9OG+99EO5QepJbsOejGwUoKpLR/mJGf4ivLnV/E2qWct3dRWenyRwRw29w8IdjEkpd ihBb/WAYJwNvTPNZn9lw/wDPxqH/AIMJ/wD4url5/wAjj4n/AOv6L/0kt6zdemng0sG2naCWS5t4 fNRVJUPMiNgMCM4Y9Qa6MPTp+xUnFPQHuTf2XD/z8ah/4MJ//i6P7Lh/5+NQ/wDBhP8A/F1g3+pa vp+owaZazfbZ1kSQNMqK06NFcN5TYAUHdBw4AxkZBwdwNUv9Se5uLO5ujpqzqVks4ozMsbQQyKds inKfPISAC+SoA6irtR/k/BC1N7+y4f8An41D/wAGE/8A8XSrZSWx82y1HUbe4XlJPt0rAHtlWYqw 9iCKXTZfP0+J/tX2nqPNMexjgkYZezjGGGB8wPC9BbrT2NJr4V9yC56B4e1J9Z8NaVqkiBHvbOG4 ZF6KXQMQPzqjc/8AJQ9M/wCwVd/+jbasPwXa+Km8C+Hmt9Z0aOA6ZbGNJNJldlXylwCwuQCcd8DP oKuW8OsRfEPS/wC1r6xus6VfeX9ks3t9v720zndK+e3TGMHrnj5ws0PG9tNeeC9Vht42kl8neEQZ ZtpDEAdzgHiuBTV9NdA66halSMgiZf8AGvXqoyaLpUsjSSaZZu7HLM0Ckk+5xXVhsU6F7K9xNXPL ZL/S5lCy3dm6hlYBpFIyCCD16ggEe4p/9qaf/wA/9r/3+X/GvTf7B0f/AKBNj/4Dp/hR/YOj/wDQ Jsf/AAHT/Cun+0n/ACi5TzL+1NP/AOf+1/7/AC/40f2pp/8Az/2v/f5f8a9N/sHR/wDoE2P/AIDp /hR/YOj/APQJsf8AwHT/AAo/tJ/y/iHKee+HpI9Q8b6UbORJxbJNLMY2DCNShUE46ZJ49efQ16lU NtZ2tmhS1toYEJyViQKCfwqauGvVdWfO0UgooorIDjPH/hN9d017qxB+2KgjniUc3dvnLxezEbgr dix5Gcjz5fDunzGK50kQWVvKYZJY4LcKJTFMkiEgY2kYdemfn5+6BXs2sapDo2lT386s6xD5Y1+9 I5OFRfdmIA9zXA3vhjWdJt47+KF9Qub1y97bQkYjuHYtlP8AYydpPbAY9WNduErxi+Wpt+QmiskF 1qV/FpdgdtxKNzykZFvH0Mh9T2A7n2BI6jQfFHhazdfDsFwdOurdjGtrfo0EkhyfmG/Hmbjlsgkn OarWOnXvghTqEz/b7S4AbU2jj+e3YZxImBlolBwV6gDcMktnp7/TNK8Q6eIb+ztb+0kUMolQSKQR wR/iKzxOIdad+i2BKxforG0Hw1Z+Gkni06a8NtJt8u2nuWljgxniPdkqDnkZ7CsT/hM9U0Vinivw 7c2sQ66hp2bu2x6sAPMQfVfxrmGdpRVLStY03XLNbzS763vLc8eZBIGAPocdD7GrtABRRRQAUUVF JdW8LbZZ4kbGcM4BoA5jQL6zsYtQ+13UFv5+tXEEPnSBPMkZztRc9WODgDk1TntPDcOj+Iho1zBP c2tlNBLEl60/2MFW/dKhYiBcpjYoUfIBj5RjHF+NK1Ftbils8Je6lbE3kskFsFklibe9wsbrGcxK oDY3F+DkYNz+w5rbw1HMt1a3Gn6Z4blsbS4gkLG8V4oiZCMYQDyRgBn3B85GMHz5r3myzuNJ/wCQ NY/9e8f/AKCKuVmaReWp0mwQXMJYwRjHmDOdorTr0CAooooAKKKKADqMGuSk+HejtIxgudRtYicr DBdFY09lBzge3QdBgV1M8yW1vJPK22ONC7H0AGTXn8V3qevxpeT6zd2fnRrMllaOkYhRs7dxwWZs ZBJOCQcAYrGti44ZczbV+xnVqxpq8jV/4V1pv/QS1j/wL/8ArUf8K603/oJax/4F/wD1qzf7Nu/+ hg1r/wACv/rUf2bd/wDQwa1/4Ff/AFq5/wC2od5f18zn+u0vM0v+Fdab/wBBLWP/AAL/APrUf8K6 03/oJax/4F//AFqyWtJUcq/iXVlYbcg3gBG44Xt3PA9TUn9m3f8A0MGtf+BX/wBaj+2od5f18xvG U1un9xv6V4L0vSr9L1ZLy6niz5RupzIIyQQSo6ZwSM9cE+proq4jT9S1DRtUsbe51Ce/sbyb7P8A 6SFMkLkEqQygZUkYIbJ5BzwQe3rqpYiOIjzxdzenUjUjzROf8J/6jVv+wrdf+h1jfEBidR8PxE5T zpn29twjwD+G4/nTtB8J+HNTfWLm/wDD+lXdw2q3W6Wezjkc/OepIzWX4t8PaJous6FJpWj6fYPI 06u1rbJEWGwcEqBmurD/AMWPqWyhe3kdjAs0qsVaWKEBRzl3VB+GWGfaq9/qpsru3tY7G6u5543k CwGMbVQqCSXdR1delGtWlxe6cI7URGdJ4JlWVyqt5cqOQSASMhSOhqjLpN3quo2l1qSLbLBFNHss r6UElzEVO5Qhx8jZHT7vXt783K9l5Ek3/CRQyTItrZ3l3C1tFdGaBFwsUm7adpYOThGOFUn2zxQP Eds08+y3naygZVkv1MZgXciuDw27bh1y23AzkkAEhj2GoWmryTaZBYrbSWkNsvmOy+R5bSHIRVww xIONy9MZHWqMHh28trS+0aLyP7Lu1SI3DTEzrGII4iNmwKWIQ4O7AznBxtMN1AOprZ+H7Eah4giB wnnQvt7bjGAT+O0flWNWz4A/5CviH/rpB/6LNYZh/C+Y0dzRRRXiFBXF+MNEa3lfXrGMsQB9uhQc yIBxIB3ZR17lfUqortKKunOVOSlHcDy3T7GTxHqC2FtIRaBQ93cxt92M9EUj+JvUdBk9dufTreCG 1t47e3jSKGJQkcaDAVQMAAelQafpljpNu1vp9rFbRNI0hSJcAsxyT/nsAOgq3WlevKtLmYkrHluo K0XjTxGrgq0lzDMgP8SG2hQMPbcjj6qar3tlBqNq1tcqzRFlb5JGQgqwZSGUggggHg9q6nxc+j3d 5HZy6Emr6hEm7G4RiBG6bpOozj7oyTjOK5r+ybX/AKESw/8ABu//AMRVxzehRiqVS115mU6tOLs2 VYdIsrcQ7ImLQymdXklZ3LlCm5mYksdrFeScDHoMRP4f0xmldIGhkllaZ3t5nhYuwUMdyEHB2qSO hIBIzzV/+ybX/oRLD/wbv/8AEUf2Ta/9CJYf+Dd//iKf9uYTbT+vkT7el/MJbW0NnbrBAm2Nc4GS SSTkkk8kkkkk8kkk806aWOCF5pWCRxqWZj0AHU0n9k2v/QiWH/g3f/4ip7SDRtNuUu9R8FQW8ER3 m4hujdCHHO8owBwOuQCR1xVLPcO9I2+8arU27cx2ngy3ltPA3h+2njaOaHTbaORGGCrCJQQfxqK8 /wCSh6N/2Cr/AP8ARtpW8jrIiujBkYZVlOQR6iuV16PUpPHOh/2Xd2ltN/Z18C91bNOpXzLU42rI hB465/DnI4jc29f1M6L4d1LVBGJGs7WScITjcVUkD8cV5sy6lcHzbvXtVaduXMN20KZ/2UTAA/zz W94ztfFK+CNca51nRpIBYzGRI9JlRmXYcgMbkgH3wfoaya9HL6cJ83Mr7EsrfZrr/oN63/4Mpf8A 4qj7Ndf9BvW//BlL/wDFVhS6pd/8IJp2oG5lS5njszLNFEHf948Ycqm0gkhmwAp9hTBc6nMljbi+ vIYrjUGhjupLdEnkiFu7ncjphT5ikfcHCj1ye7ko/wAn4LqLU6D7Ndf9BvW//BlL/wDFUfZrr/oN 63/4Mpf/AIqufS61C815dI/tKeAWyziSeGOLdOVFuyEhkYA4mIOAASM8A7Rt6TeSX1h5syqJUllh coMBjHI0ZYA5wDtzjJxnGT1pxp0ZO3KvuDU2fDmqX+neI9P06S/ury0v2ki23UnmNE6xtIGDH5sY Qggk9RjGOewZrjV7u5ghuZLa0tn8p3iwHlfAJAJ+6oyBkck55GOeEsP+R08Nf9fU3/pNNXead/oe sahZPx57/a4D/eUgK4+oYZPs614+PhGNblirI6aG0pLdLT7/AOvzD/hGdIbma0+0N/euJHlb82JN H/CM6SP9XbPF/wBcZ5I8f98sKwviPpT6vpFpBFqAsXWfcJGmaNTx0JUgnr0rzS1sNCs7KL+2L/W5 7nDGR7S6m2YDsuRjPBxXKqcX0B4quvtv72en2tpPqGuXttZajdpp+nlELzMLjdc/eIBkDHCDbkg5 3HGRtOddpdbs3VH+wXwbO0BjbyHHoDuDH8VryKxsvAsu6Gym8RK4y6xG6nTzWJ+6uV5Yk9Pqa3PB K2Xh/wATazNrd3HZtDHGIxe3mRCrAkgM+OeBkjFHJbbQf1iT+JJ+q/VWf4noY8QWsRCahHNpznj/ AEpdqE+0gJQ/TdmqerX9/ot4NWVmvNDZALmKNAXtQP8AlsmBl0/vLyRjI7ikfxxoDPDFFPPdi4lW BHt7SWWMsxwBvC7P16Zq82g20TGTTpJNOlJyfs2AjH/ajPyn64z70veXmH7mf91/ev8ANfiaiOsi K6MGVhkEdCKWuRub3xHoGqvfX6rf6K6gTm2X57YjjzFTrt/vLlu7AjoentLy2v7cT2k6TRHjchzz 6H0PtTUk9CZ0pRXNuu62/ryepGNOtooLqO0jWza5LNJLboqMXIxv6YLcDkg9BXLbPHfh8/u5LTxP ZD+GTFpdgf7w/dv+IUmu0oqjIzdI1gappZvZrG803azLJDfxiN0x1PUgj3Bwa0qgvLS2vrKa1vYY p7aVCsscqhlZe4INeDal4iGjas0PgTUr+x0tMoyySieBz6wpIG2DuDnB/u45OdWrClHmmzehh6mI nyU1dnvdxcwWcDT3M8cEKDLSSuFVfqTXnHivWPhvql1HdXWo2kupRLtiurO2+1nH91gqsrL7N07E HmvKLySbUrj7RqNxPezgkiS5kMhXP93PC/QYFbfho20Q1Se4ChYbMMrm1juNhM0S5COQpOGI68Am vPeZKT5Yx+89hZHKMeapP5L+v0OgPjey1bSbjwlEmn6RaXkMts+pm3eKBVcYysOBtY5b7zqFODuf 7tad7rPh/wADXl/cif8AtfW71Sbi1s4IoYtzHcS/lqOCTx5rSOATgnc5bmdVs9NWS5uriGSeKDyI s2wS1+0GVXkWXaFZUGxVG0DJ6nByKm1Hw1YWMNtYJHKs0dvebbiOJY4mMEs7EkclmYKBjI2jactn AydaTTsv6vb+tQ/sujzRvJ2f+V/y8r/MsaL4h8Df2jFqWr6TJHeRNuhSLS0SCA9iqxlizD+82T3A XpXotl8RfCF+cR67bQsTgLd7rcn6CQLmvNrLRtIt73U0kt7mb+zvPtZN0yYlcQzHzFGz5MeS2B82 CynPy4biyAQQQCD2NV9fnTS5or5GiyalVbVOTVrb26n1HHIksayRurowyrKcgj2NOr5h068vdGm8 7Sb24sJM7j9nfCsf9pPut+INeo+Dvic99dw6X4gSJJ5WCQ3kQ2o7HorqT8rHsRwSe3GeujjqVV8u zPPxWU18OnPdeR6bRRRXYeYZ+vf8i9qf/XpL/wCgGvO9MuVsngkliuTHJptqqtFbSSAkeZkZVTj7 w/OvRNe/5F7U/wDr0l/9ANcdp8vkeG7Wby5JPLtEbZGuWbCA4A7mvHzf4YfP9DmxE1G0WrqWm9uq e9n2Muf+0vMm+yfa/wC0d9xu3bvK8va/lbd37vOfJ6c9c/xU64DGyZbFtUS3Mi+Y8yzMV4bOFJEx 52A7SByD0Dg6Ntqjvbm5uEthbEZSa1uPPVjnG37oJJJwAAckEcHAMi6xYvJDEJmEsxKpE0bK+Rty CpGRwynkdDu6c14t2aSrYhSsqXw9tdVr0TXu/ZX2Vvc5yxh1Bbh5Zo79bp/s6ZPmY2LdMGB5Zf8A V7e5yCxycsTMEv5IYIwdQEjCIX5LSr+8MsWdhPQY87Jj+XHtit86rZCGGUzfJPF50Xytl1+UcDGc kuoA6knAFNt9Ysbq6+yxTMbjG4wtGyuo55YEZXp3x1X+8Mu73saSx2Jk5VvYPR32dlbS22ytt0lZ 9LGRdzHTbi0acXb21vrMPlYjknkKeWCcABnf5i3r6dq7X/hMtL/59dc/8EV7/wDGa57Uv+P/AEP/ ALCcP9a9Br38r/gfMww1R1I8z3/4C19Xu/M5jwReRXtjqs0Szqp1W54ngeJhlsjKuARwR2rU1zQr TX7NILlpYnifzIZ4WAkifBGRkEdCRggg56VS8K/8xv8A7Cs//stdBXpptO6Og4v/AIV2v/Q0a5/3 zaf/ABij/hXa/wDQ0a5/3zaf/GK0/EXjbQ/DB8q+uTJdldy2luu+Uj1x0Ue7ED3rhLz4y3juw0/w /GifwvdXXzfiiqR/49SqY50/jqW+ZvRwlatrTg2dR/wrtf8AoaNc/wC+bT/4xR/wrtf+ho1z/vm0 /wDjFcYvxg18MC2k6aV7gSyAn8cVs6b8ZLV3Cavo1xaAnHm2souEUepGFb8lNRHMlJ2VT8Wazy3F QV3Tf5/kbX/Cu1/6GjXP++bT/wCMV0Oh6FaaDZvBbNLI8j+ZNPMwMkrYAyxAA6ADAAAx0qfS9W0/ WrJbzTbuK6t24DxtnB9D3B9jzVytpVZzVpNs47WCiiioAKKKKACiiigDzWeeWPxpq6o2BLrCRPxn KDT43A9vmGasX+qvZyThLdZI7WAXFwzSbSEO77gwdx+RuCVHTnniOWygvvE3iVZxJ+71SN0McrRs rfYrcZBUg9CR+NJcW+jRzw2tzcqszAKsct42+ZSxwrAtmQZJADZHJHc18tjLfWJHJfDyqrni5Nbp LzbvdNPbTy87WJV1OYrPcfZV+xRGVfMEwD5jLAkq2FAypAO49RkAZxnR69e3Oo2dqlqsJM4Ewcuu UZJCMb41PWNj0A4AzyduudKsjM8jQ79+7MbszR5bIYhCdoJyckDJ3H1OY00TT45lmWKTzldX8wzO XZl3AFmJy3DsOc8HHQAVzXiKnXy+KnzU23bTyfn72vqra9EUrHXJJ7S3nNvug/cRSyPKPM8yRUIw oUAj94uTle+BwM2NO1OW/W3W6tI4lu7Y3EQSUyZT5chsquD869M9/wAZ49HsYWiMcLKIgoVBI2w7 QApK5wxAAwSCflHPAqaGxtrf7P5Ue37PEYYvmJ2odvHv91evpQ2ia9bASUvZ02m9vLR/3rb2+Wy7 7PgZmf4f+G2Yks2l2pJPc+UtJff8j9on/YPvv/Q7asPwX4L8K3XgXw9cXHhrRpp5dMtnkkksImZ2 MSkkkrkknnNXItB0fRPH+kHStJsLAy6feeZ9ltki34e3xnaBnGT+dfZHcaXjeKSbwJr8cSF3bT59 qqMknYeBXEo6yRq6MGRgCpHQg16pXJX/AII8J28c97cxzWNugLyGLUp7aFB67UkVVH0ArrwuJVC9 1e4mrnCW3hzTbWJIo1ujFH5eyKS8mdE2MrJhWcgYKr0HbHQkVbv9NttSSJbkS/upPMjaKZ4mVtpX IZCD0Yjr3pt5d/D22t4bmC38Q3tvLNJCJYNTulUMgQn/AFk6kj94MEAg4PtnGvLaSTTmvNN0+N2W +ezMEetahclsbMSIyypuUlwudo5ZP72Bq82w0bqx0QwVeaTUXr8vzNOXQNPlW3GyeM26usbQ3UsT YcgvllYFiSoJJJJPPWtCKKOCFIYY1jijUKiIMBQOAAB0FcrLaT2viFtLlNrcRxwi4kuLe/1DaYxD 5rbP9KO75c4OQDx0zxct59Ph1C6sr/wvqlw1pN5EraZ4hu5GLbtmVjd1OC2BnPVlBwSMqOc4a+i8 ipYDEJJuPS/yOi05S/jXw6FBJSeaRgOyi3kXP0yyj8RXouoWRvIkaJ/KuYW3wS4ztb3HdSOCPQ9j g1zXg2fwebi5i0GQfbwCs6XFw8s+AecM7MWTPdSV6YNdjXLiKyrz51sYRcqcuzRw/jGG/wBf0eCC ytQNQtblXmt3Y/LweQQDkHscc47HIFPQbfxDpumQWr6VuaLduKscHLluCR74ruL2wF0UmikMF3Fn y5lGceqsP4lPcflggEYtxrt1cXg0OHy7XUids04YMkS4BymfvOQQQpHHUggDdzuXKveNHTU1zU/m u3/A/Lr3eKyatd6i141tO89sTEEimQiHIBxt2nDYIOeuD6VW0CyuIviVd3WqWCK+oWKtBJKgLgwF VbnAwT5uePT2rp20P+y1jutDRUuoU2vG7HF2uSSsjHktkkhzkgk5yCQYdS06LxjBp9xbXktoLad0 uk24l2MhWSE8/IxyvPoMjqDWfOq0GkZbHOeMtYuIvEUN9bzXkNromYy9vY/axPeTIuyDYCGVtrR4 f7recV3o2M63hb4kadrl6dI1GJ9J1xHeP7JckATFHZGMT/dcbkYcE8qeuM0/WPC1xFaqmnvcz2kW 9orZLgx3FozRvEXtpScZCyPhHyASMFcAVkf2FoVzoV/dXOtXMelW8/2zULCK1iijQQlWjSSIxmRN kUUMeFK7ljBxliTCbpaPYNz0muQ1zTbnTdYfW7drpraYKLn7KMzW5AwJFUA+Yn95GBx95ecg41r4 k1fwm2onWpI7nSLKWZpfMcJPYweZttzudybgSIcgjncrplnGyul07xdBqviNdOtIHaze3kkjvGyo eRCgeMKRn5RIuSe4YdVNbqUZoqE5Qd4uxd/tK5075dWjXyR0vYQfL/4GvVPryvuOlaqsrorowZWG QQcgisG/bUdF1N9Qi+0X2l3BAubYAvJbHAHmRDqV6bkH+8vOQbTadNp7tNpJQITl7NziNvUqf4G+ nB7jJzT1Xmae5U/uv8H/AJfl6FTxxaXt/wCCNYtdPVmuZLZgqL1cfxKPcrkfjXzyjK6BkOVI4xX0 5ZX8N8j7AySxnEsMgw8Z9CP5EcHsTXE+K/hfaaxcS3+kTrp99IS8iFN0MzHqSByrE9SPqQTXHjMM 68U4PVHo5ZjVg5yhVWj/AAPI7SynvpTHAqkqu5md1REHTLMxAAyQOT1IHUiiaO5sJZraQtGzKFkV W4deGHI4ZThWB5B4I7V0UnhjXdKsLvTdU0yaGKWaOZb63RrmEGMOMMIwXVSJD8xTqAMYORBpGt6T YeXbR6yiJb3ZkvYirob6Lan7raB8w+WQASbRhx0ywHlPDTj8SsfQLH05t+zal5f1+VjL0261X7db wadd3MdzJi3hEUxQ4Zs7AcjALHPpk5qAX12LVrUXU4t2UK0QkOwgMWAI6YDEn6kmuu0zxTFBq9u0 +pTiygtrJYVJcrG6mAS7V7HaJgSByCw53c0v7cQTaZDJf+asME4kuArcXDPP5cpJAc7fMVwcErkk DcSKnkjb4v627lqpNtt0+35N9vl6mbaTa9dxpcW15dstgpWNhckGAeW7ELk8DZE3TsuPQVkV2Y12 wSyniudQ+0XRgKSXW1z57+TdqDuYBjjzokywHT0GafceMdLmvgtvc2UmVuDaW0UU08kKmCRVjZHL KoyyArGpQ45ICjNKippWlqZvFSpN3hZfccTTJomniMCRtLJL+7SNRlnY8BQO5JOK6TTvBnivxBOZ l02eFZWLPdaixiyTySVP7wk/7vPrXqHhL4d6f4blW+uJTf6mAQs7LtSLPXYmTjjjJJPXkA4rWhga k5Jy0RhjM3oU4OMHzS8tvvOo0uK5g0myivZPMu0gRZnz95woDH881boor3j48r31t9t0+5tS23z4 mjz6ZBH9a84s9XsrHTYtN1K/g07UbeFYZoppVR0YDbuUN1XIyrYIIr0+o5YIZ8ebEkmOm9QcVy4r CxxCSbtYxrUVVtfoeSzTaNeGd7vxBorSShc+UURZCrKw8wFzvxsAHI4LDvxPYXWg2NzHONb0dSqS KY7dooky5j5ADH/nmOpJOeoAAr0/7BZ/8+kH/fsUfYLP/n0g/wC/Yrj/ALKj/P8AgaSlXlD2bqad rLtbt20PLZZfDcsV6h1vTCLmRXAadGVdreYFYFvmBkLk9OHI4wMP0q60HTLm4nGt6ODOiKY7dooU UqW5ADHruHUk8dcYA9P+wWf/AD6Qf9+xR9gs/wDn0g/79ij+yY7c7FJ15U5UpVG4y30WtrfPovuO Ct7i38Qa3pcGl3EV2trdrc3MsLh0iVVOAzDgMSVAXryT0Br0WmxxpEgSNFRR0VRgU6u/DYdUIcid yaNJUo8qOI0PxX4c0y51y2v9f0q1nGqz5invI42HQdCc9jUXi74k6LYeHpm0PXtKu9TlZYYEguo5 WVmON+0E5wMn0zgd63PCv/Mb/wCwrP8A+y1N4r8Px+J/D1xpjyeU74eGXGdkinKnHcZGD7E1rK/K 7bnRT5VNc2x4Vo+kHV5LqV5LuWUMGkFtB9puJGbOXK7hleOWzwWUd+LUfh22kjtgNWi864glnj/c v5YSNpAzM33gCsZIwpJPBC8E05o7nw5qM2navpcDTHkRXIYB8dHjdSpZeT0OPUZAwsviC9uLtLqb ynmEE8BYrjcJTIXJA4zmVsYwOnFfONKLtUWvz7n3EXKavQl7vS1u3+fpYmTRIpb62jhuLmWC6gM8 IitC87gMyECMNjOUY/extGc5+Wp28PH7VcaUFZL+JopkkkjdcxOq/K6jO1xuTCjqSygsSgNCHWpo o4YnggmgjtjbNE4YCRPNMvzEEHIcg8EfdA9cpqOuXGoRSLMkEauY2kMSbA3lx+WnHRQBu4AA+Y9g AJvTttr/AF+v9d7ca/Nvp/wf8t1/Ss6b4lHhfxI2qaWHi0/eqTwtyZoAcZfkjfjLZHQ5AwDivoqv nfRdM1Hxpr016ljFcW0Lw3N2olMRudzNnZkYwzRtuIIAyQAOg9n/AOEnuov+PvwzrMA7siwzj8PL kZv0r2ME3GDU36eh8rm06U6y9nvbX1/X1Ohornj420KME3U9zZY6/bbKa3A/F0A/HOK3oZormCOe CRJYZFDpIjAqykZBBHUEV3J32PLH0UUUwCiiigDgYvl8VeKAeCb+JwPUfZLcZ/MH8qoagWgurkW8 M7vPgvbPbGSG5+UL98DCEgBcscDBJXnJ7LWPDUOqXQvILy5sL0II2mt9h8xBkhWV1IOCTg4yMnnB IrN/4Q2//wChpv8A/wAB7f8A+IrxcRl1WpVc4tWZzQpTp1nUVmn0+7yfb/Jp6nH3Sat5moss935+ y4xHHDLjZtfy8Pv2Z/1f3F3Z4P8AEa1Lu0vInjhtrid0uk8iWRnJaM5LGQEcKSpkGem7ywAAK3P+ ENv/APoab/8A8B7f/wCIo/4Q2/8A+hpv/wDwHt//AIisf7Lr91/XyN6lWvPl92On9Lpsnt9zbONu otXe+Oy7vY5GvFDrDBJhYfNGDuLGL7u0naueobjfXWAJbwAFiEjX7zsWOAOpJ5P1NTf8Ibf/APQ0 3/8A4D2//wARSr4JMx2ajrl/e2p+/bFIo1kHoxRA2PYEZ6HjIp/2XWdrtf18jHFKtiYxi0kl2+XZ LRdL3stLl7wOjR+APDaOCrLpdsCD2PlLTdQ48daEe5s71fwzAf6Cl8Ty6zZWlvc6RPbwwQsftYe1 MzCPHDKoZc7epA5IzjkAHnNV8OeJde1LS759a0ya3hhm2S2cdzacPsI+aO5ywO31A+uePclUjH4j osehdBk186+KPFlx4xv/ALS7MunIxazt+wXs7Du5HPtnA7k+jN4N1oKVa+Eykck6zqaDHpjz2/nX jyWF3pthpwvIDEt1axz2zE5EsTKCCD3IBAI6g+xGeDHVHKl+7enU9jJY0niP3m9tPU29I1OKytHj XUdS02YuWaWxy3nLgbVYeYgG07iDzneemOb9p4qt7R2eG08kG6uLlYlUFY9xhkiUYI4DwKG4Hy5x z0wxaRvojXqFvMiuRFKGPBDqSm33+STOf9nHetK90qw0mSVrtbmeNJ2tBHFKsZMsap5rbip+Xc3y jbkg8kYwfLjKaWmx9JUhSlKz1b/r9b6gdfjhNzNbR5uJbW1tAJ4Ukj2JGgclWyCd8abcg8E9DjEs XiO3jvl1J4JXu2ghhlijxDH8jDJXb935I0A44Ziy7Si1SfR44TqYaVnFvZxXULAbdwkaLbuHODtl 5APB7kddLXfDtvpw1ELY6lZpaOVhuLtwY7rEgXan7teSCX4J4U8dxS9rZvt/wf8AgktULqPf/gfP scy+2O6EltLKDE+6CYfu5Fx0YYJ2n6E/U17j8PPFc3ibRZVvSp1CycRTuowJARlXwOmRwfcHHFeF Myou5jgV7X8MPDN1oWjXN5fxtDd6g6uYWGGjjUYQN78scdt2OoNdeWOfO19k83PY0vZxb+P8bG94 m1S/0+1ii06xu55rhihmgh8wW645cr3PoOmevAqlo0mlahb3OkCwu4mgCTTR30RWRy5bEhbOSxKN 82c5H0rqa4nVJ9Wt/FWuSaLbJPd/YrAbWUMQu+5yVQvGGPTgyJgEnJICt6WIheNz5mMnF3RtZ1DS +CH1CzHcf6+Me4/5aD8m/wB41z03iNJbx9W0DS9VuZUcw3Cx2xEd0EJUg5PDD+FiPY8Hhnhi/muv ENymv6nqKaglwV0+zukNmjr5CGXy41ws4VzIOWl2hEIbne+h4W0mC50R7mN5LW7+33w+0QNtY4up cBh0YezA1z0INS0N3OFT49H3X6r9V9zOthk82GOTY6b1DbXGGXI6EetZ2p6HBqEy3cUklpqEa7Y7 uDAcD+6wPDr/ALLAjuMHmm/bdR0/jULY3MI/5ebNCSB/tRct/wB87voKvWl9a38Pm2lxHMgOCUbO D6H0Psa7bp6MznRlFc267rb+vJ6nm8vg2wN/DpU2k2VtqP2mO7t3tk8u1e3Ro0uVWNB8u+NmV1cM H3qpdgqhNL4kXt9plrpN/pE0S6pDeeXGjKHLpIjIVC5Gcts/KuhvvCWmalq0upXb3rSyRrEyJeSx x7VyQNqMARlicHIyaxfFeg6Zofhe7utG0q3t71SrCa2gHnHkZO4DcTjPesvY++pXM7nMabr/AI/v 4ZJLnWNL05o5TEY7qzO7IAPY+hFXrWPxzHPOYfGOjStO/mFDaSSYOAPlBPAwM4HHU1laSukajazS 61YzzzG4cr56SKxUqg7+4P5VJNoXhdL6F9M022to4mzJLulDyAjBUHBwOefUcV0aE6lnRNS8Q654 1jtZ9Yt3S2gaVLq2tTGJiGxt55aPd1HfHB716bY3v2rzIpU8q6hwJYs5xnoQe6nnB+vQggcRos0d 14/t5be3WKCPTDEfKUiNSJOFBIHbnFdhq0EqouoWiFru1BIUf8tU6tH+OOPQge9Q9NUdEHz2py+T 7f8AA/LfvfSqre6ZYakmy+sra6QfwzxK4/UVNbzxXVtFcQsHilQOjDupGQakqjFpp2Zzcvw/8ITA g+G9MTP/ADyt1j/9BxUP/CtfB3/QBtvzb/GuqopWTGpSWzOdh8BeEYCCvhvS2K9DJao5H4sDz71t 2tla2MXlWltDbxj+CGMIPyFT0UybhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHHQXWr6VpmtXGm6O dQuDq0pEDzeT+7OMuCQd2PQde1Lp13rXiGN3j8Q2doIztlgs7IieFvRzMTg+xjFdZcXENpbS3NxI scMKGSR2OAqgZJP4VwFxceIrMQa/AdPtINSlaTUpr63eVrGAL/o42q6fKOfMJOFMjN90MRjWk0tH YaNPU/Aena1YS2+q3upag7oQklzdNtjYjhxGu2PI6g7a57Svhn4e1zR4bhWv9Nu0LQ3Udtc7lSZC VcASh8DcCR7EVr+HNd8UTWcmsa6NCPh90a4gvLZpoZRbgMVlaJg4+ddjbd4KgnOTwLmj6tY/8JTM bG5SW01VdxUZDRXcagMrKeVZowpwQCPKb1rCn70uWpqaRqTp6wbXoYo+DGj5Gdc1xh6F7cZ/KGtn TPhj4V02RZTp5vZV5D3sjTD/AL5Pyg++K6+iumNKnF3jFL5Dnia01ac215tnN2YC+PNaVQABp9iA B2+e5rermJNQt9N8aa3PcuQpsLFUVVLNIxe5wqqOWY9gK0o/EFn/AGReajdCWzSwR2vIplzJb7F3 NuC5z8vI25yCCM5rjrxfO2ZrYq6wvn61aWmptjRpgFVV+7NPnhJT/dIxtHRjkHqAelAAGAMCvMZN XkmuZtb8a3NzoWhyWriz0ycKI5Yjkt55wW+0narrGu1lHClz5oHV+HdXnMVpZaklzHJcQrNZyXSb JZEKhjHIO0yDhh3xuH8QXehJJcrEzo6KKK6RBRRRQAUUUUAFFFFABRTZJEhieWV1SNAWZ2OAoHUk 9hXF+I9cM2izajN/o+hI8cYMknkm7MjrGpdzzFBlgWbBYrk42jDzKSitQLer+JLaWMqNVt9L0rzP Jl1SedYhI/OYoWY4J4OX7YIXJyV37S0gsLOG0tYlighQJGi9FArz3VdXstQ8NfYWuLbWLqOTzrD+ zdImS1uhChka2jkzJGxeNJojtc8Oy7TgqbOg6XZ+HLfTdU0rW76awv4Wlj0m3iAhu5JSZFMMT5MC ASN8qkAAIXPysW4qjdTcpaHY61cfY9C1G5zjybaSTP0Umqdr4e07UfBumaTqdnHcQRWkKBXHKlUA ypHKn3GDWD4uv9Us/CerW2sR26rqNpJDbyW27bDI6lRE5PU88PgBjkYB27u9ACgADAHAFbUKbjdS BvseV6p4Fk8Hl9U0PUZJVleK2js7pQT5skqCJhKOipJ5bkFTkIQTgmsaDwL4qitlsr7Rra7tldpY zbamImR2ADctGcghVyCP4RgjkH03xV+8k0G2/wCe+qxceuxHl/8Aaea2658RTpqSSidlPH4iK0l/ XrueGXuheM7eDVri68PQiKW1WEuNQhSOGONo2GCzdAsQX5jnuTnObtj8P/EXi2ebW70W2hxX00k4 glDTzIGYnBUbQPz+oHSu2v8AV7XXNbkttNjnv5NElElxEImNrNIPvRCT7hnjyrBSeCR3BKddZXtv qNnFd2snmQyDKnGD6EEHkEHIIPIIINVRw1Ka95FPMsT0lb5Ly/yRzPhz4daJ4dnS72y31+nK3F0Q dh/2FACr9cZ9666iiu6MVFWirHDOcpvmk7sK898Qef8A8JpeY+3f2f5Nl/aH2DzfO8nF5t2+V+9/ 1vlZ2c4zn5d1ehVxN/qk2nePL6G1tkuLy+t7K3t0llMUe4C8kJdwrEDbG3RTzgcAkjOt8DEtyHTP 7Sk1zT7o/wBqi5ubq5muxN5wgFgfOEA2N+6STi2yoAl6lhy9bngv/kXW/wCwhff+lUtWtF1P+1tN F0YfJkWWWCWMNuCyRSNG+1sDK7kbBIBIwSAeBV8F/wDIut/2EL7/ANKpaxw795jZtXV3bWNrJdXd xFb28Y3SSzOERB6kngVyd54n8C3k3ntr2nx3IGBcQXISQf8AAgeR7HI9qxfjNJcrpGjJbjfm+LNF kAPiJ8fkeR7ivINAS8guLi3u9ykQwybWk3ncd4Yk+pK9q7VTU9yqblF3i7HuP/CdaZZf6rxVo+ox j+G4mWGX/vtQVP02j61PD8S/CN7iC61CCJz/AMs5Csin/gSFl/M15JUVxdW9pGJLmeKFCdoaRwoJ 9Mmn7BrZnReEvjj92n/A/A9q/wCEv8ExN/yF9JRv95QaU+NvBRGDrekkf9dFrxIG1mKFWiYyLvQq Rll45GOo5HPuKhmurG2VTLfxwhiwUvOACQcEDJ7Hg+lHs5IXsaL2k16r9U/0Pco/GngmFt0WtaSj eqyKDUp+IHhIKSPENg2AThZgT+Qrw918sAvcuqkhfmKjknAHTuSBSqsXmld++VQGIZskA5wcduh/ I0ezk9g9hSjq539F/nb9T17QfG3he00Kzgn1/TkkWPlDOvyZOdv4Zx+FaX/Cf+Ef+hi07/v+K8Uo qlRsrXM6ic5ub6u57X/wn/hH/oYtO/7/AIo/4T/wj/0MWnf9/wAV4pRT9l5k+z8z2v8A4T/wj/0M Wnf9/wAUf8J/4R/6GLTv+/4rxSij2XmHs/M9r/4T/wAI/wDQxad/3/FNf4geElRmHiHTmIGQPPHN eLUUey8w9n5kHhL4ha7d+NNNml1C8llvLu3iuIXnLQFJX2sBHkqgXPGMHOPU5+la+drH/kO6L/2F LT/0elfRNRNWdiJKzCiiioJCiiigAooooAKKKhu7uCwsp7y6kEVvBG0kjnoqgZJ/KgDE14/2rqVr oCcxNtur/wBoVb5UP++4x7qjisDRjrt5ezXK3Gorq0qFZ01KB1sdOXezCKKNfLFy/ITzQxyELbwC qPnHVLseJ47G51ldAnvLZ9X1CZzB5vl4ZYbePzSwARI5HkIQgFM5G810k8VhrPgvTdT8X6ZAxgto 7+4tp4SUim8ohh5bZyRvYBWyc47gGuGrPmkUjG8MRNq2laPpYmeW0ZU1S6XCiKOInMMMIABWFnXc iv8AMI12tjhR2l5oGlX+pWuo3NlG17asHhuBlXUjPGRgkcng5HPSofDljPbWMl3fJt1C/kNzcrnP lkgBY8/7ChV9yCe9bFddOPKiWFFFFWBQGjaf/bjaybZTqBhWDziSSEBYgAdB948jk1W1bT5/PXVd NUfb4l2PGThbmIHPlsfXklW7EnsWzsUUmk1Zgee+JZReWVtr0FsupzQ3A/s+G6JhtNMkVG8y4uue seHySMqQqoFYlm5uwvbnUotf8RiZl0u3jW8uFljeG5vdqZW9gRjtgVUTbFw3miMrI2fmX0XWdO+y yXGoQWourW4TZqVjs3iePGC4Xu4Xgj+NeOSFqPxAPCl1oY1rxBBpd1pttEZkubuBJlRWxyuQfvfK MDknA5OK4pxdN2K3L+kalNLJJp2ohV1KBcsVGFnToJUHoe4/hPHIwTrV5/rOoak+t3hkktYItPv7 a3sykLC5Tz1jVJiS+JImld42XauQjkNuTB6/SdU/tGGRJovIvbdtlzbk52N2IPdT1Ddx6EEDppVO Za7iaNGiiitRBRRRQAVBeXlvp9pJdXcyxQxjLO35Ae5J4AHJJxXI+Rev4y13VNOctc2n2e3Nuz4S dBH5hQ9g37zKt2PsTS6nqH9lXdhrXidFjtHm8pNrFotOduEeTjB3cqZSQELKoGGZqylWirrqOxn+ KtfmS1e6vrSVYIgk8di8JcRw7wrXc6ggyLFwxiQkrlC+NwKafhC+n1G91GeDW7rWdGCRx213cRRI GnV5VmCGONA6ACL5gCpOcMcEDmJI9TtXi0q4mfTtG1K9z4c1BxGtzpc4UukTxMABE4Eion3gjeUw Xdhdrw3YXmgW0mkWCwjUpyJp7OCQyafprNnc0eVV1Vz84hz1JA2rlq5ZXn6j2LGo6aRrcbXt7Prt yLk3el6XLFCkdqwXaJGZU3YQs+HYnG4YVnAJ6PTNI+ySve3coutSlXbJPtwFXrsjXnant1PUkmpN M0qHTI5CrvNczENPcy8vK3qfQDsBgAdAKv11U6SgtdxNjZIo5kKSorocZVhketOoorURyfiu+W08 Q+Gk8mWeQTXE0UMK5aRxCUAHYf608nAA5JApuoHWLu2fRtRvRpU+oYFvfafyUXIMkIZukuwMFfA6 7goK4rrcDOcDI4zVe/sbfUrKS0uULRPjocFSDkMCOQwIBBHIIBrKdJS16jTPOL+0bTk/snw5qKaD 4SiQw6lqMkqqls6sqFLV3bIlYkq7nKhskHzd4Ohpvii3TXdQMELW8yHzr/S2YGXyCcR3aoPmUldh eNgHAIyM7fMdrWj32sT21jPdRprmnEy6dcXCbreQFkU3XlDh54k3bQeFZs4AYENt/B2o6Na2ulaU LWe0j1KLUH1O7uWW93eaGm3bYyJXZN6b9yZR9hBAJbmTcHruPc72KWOeFJoXWSKRQyOhyGB5BB7i n1yNlrGnaTqV1b2WoWtxpaTbLmOGZXOmzMxGHAPyxswbg/dbP8OdvXV2QmpK6JCvNfFv2JPFN/Ne yWMXlQ2LRSXmsSaaEc/bFyssYLFtpYbe4J9K9KrkJ7yex8bazLb6Zdag5srFTFbNErAbrn5j5joM cY655HHWoraQY0c94RuNLXX7aCyvdHJd5X8q08ZXN6zMwZmIgdQrkkliT0yW6iuw8F/8i63/AGEL 7/0qlrO8Jz6paxNYXvhzUbUS3t5cfaJJbZo0WSeSVQdkzNnDAcKefbmtHwX/AMi63/YQvv8A0qlr Kg/fY2cx8XP+PPQ/+v1//RT15VF/yHrv/r2g/wDQpa9V+Ln/AB56H/1+v/6KevKov+Q9d/8AXtB/ 6FLXo09i4bF6s/U28qbT5ikrpHcFn8uNnIBikGcKCepH50X2t6bpsxivLpYpBGJNpUnKk44wOee3 Xv0oXW9Ne2a4S6V4lm8jKKW3ScfKoAy3XtmrbRd0ZrWNxPqH2iKNo8iaa2LgqI2/c4Df3d5VyR1I Zs4JNFv5lshn2XdrcSSS5BtTMrDzpCAwTJGAxIIIB3DlgMCzfeI7S0gsZ4v9Ijum4ZM/LGBl34B+ 73HB6+hpl14khTP2REuWPkqib2RmeTlRyuACuTnPbGBS07i0LN7AZ9Gt4Ws1QGS3326gMqASJuXj ggDPtgVmywX8U00b/aAixwxG4UO5dFMpBOwh2PKBsEHJz93rtWOpWmoq7Wsu/ZjcCpUgEZBwQDgj oehrMi8TxXN4lrb2srSvdmALICnyquXfkY4/u9enTOKHYHYrSJqk2mIHa9SWO2u/ljypZlcCIHBJ zgZHJJx1IJzJdxXqTPCJblLKOVgrbJpWPyRleUYORky8kkdvTFzU/EFtpeoQW0ytsaMyTSAMfJXo pIAOctx7fjVuPVbGW+ayS4Uzgsu3BwSoBYA9CRkZAORRZdwsjPUXY1C181715NqBhsKjoNzfKTFj OQVb5uSVPCA0rJ72XTIHja+ZntFNw8hY8kptK+vybzhPmPch8GtRtfspIFe1mR5HlSJEkDx5Zxlc /KSARyDjB9adY63pFyois7qLbHCZNoUqqRqcc5AC49PTnpRp3DTuZtsboDZffbjZpI4UxrMrnKxl D8rNJjmTqTjocEACXZqB1VC81yuGj2IYWbKbV3bmVhEDnfnIJ9P4a1LHVbPUmkW1lZzGFZg0bLgM MqfmA6jmoTr+lq0oN4mI4vOZgCVKZxkNjDcnHBPPHWiy7hoXoNvkR7N+zaNvmZ3Yx33c5+vNSVnt rempbLcPdKkTTeRl1K7ZOflYEZXp3xRY63pupTCKzullkMZk2hSMKDjnI457de/Squh3Rq2P/Id0 X/sKWn/o9K+ia+drH/kO6L/2FLT/ANHpX0TWFXcyqbhRRRWZAUUUUAFFFFAGL4o1W+0XS476ytoL gLcRpOs0hQCNjtLbgDjBKnOCMZ+tZOoXt74ikg02PSrm38k/abuK8BjjcpgxReYoZSGfBJXdhUYE c4rqry0gv7KezuYxJBcRtFIh6MrDBH5GuTt7XUda8PCxXW7vTtY0qdoHuoVRt8ioVVpEYEOjK6Sb eOSMEEA1hXlKK0GjlbvU7PXZ5tD1iGCO7ll2voPiJgY/OZEJFpeRhsN/pAIHzvgqFWIV0thpzTXl nov2nUZ7S3caldpqEyzSQkndDbFxncA+W5ZyPLA3EEVD4X8PX1hYX/h7xFo9lqVtNLLey6kojaO/ leZn/ewkApIBsIxuXCgbhtArT8I39usclrfM1tr11I1zd2042uWPGEzxIiqFQMpIwozzWVJKUvQb OqooorsJCiiigAooooAK5XV9Pt9NhvUuI/M8O6grx30IJAty+Q0gI5CNk7sfdPzdCxHVUjKGUqwB UjBB71MoqSswPODpviPS9Y1G+Mb6oyJDs1a+iikZEVpseRawBGcokzqzF0ZtzbFbhG0NDg1fUdJj 8RC/W4v5ZHmsy0axRy2jY2xkKMhHA8xd2Xj8wKxYq261fabFZ20mgXryDQb/ABBE6kAxBjg2zEg4 RxlVYYIDFQVOw11FcE3Km/MvcwrrxfbLppksYHudQ2O32Ena8RX73mnnYARgnnP8O7IzsaXeHUNJ sr1kCG4gSUqDnbuUHH61U1O3hj0zU5o4Y1llgcyOqgF8IQMnvgcU7w1/yKukf9eUP/oArro1XUuS 1Y1KKKK2Ec34d/eah4juP+euqEf98QxR/wDslbU8EN1by29xEk0EqFJI5FDK6kYIIPBBHaubsbbx No7XsUWlabdwzXs9wko1F0cq8jMoZTDgEAgcMelW/wC0vEi8N4ajY+seooR+qg/pXBUpVHJtIpNF DSLF7G1bw94evbp7O3kZWvLlxKLJO0ERIy5XoA27YPvE4CnqNP0+20y0FtaoVTJZixLM7HqzMeWY 9ya53Rm1m315lXQLiz0u63PMJbiFhDL13oFcnDfxDHX5u7Z6yuqlBRV+omFFFFaiCiiigAooooAo 6rpkeqWojMjQzxt5lvcIPmhkHRh+ZBHQgkHg1z+oatq76dstlWDU7G7t21CBITKZLbzB5jQjOSGQ MRgM3DKBvwR11Zmr6Y955V1ZusOpW2TBI33WBxujf1RsDPoQCOQKyq01NX6jTOE0y80uVItUnvLa w8PxandSW95qQa2a+iuYRK0QEgXdG0s0jZ6EW8fDH5xvaN4istPs1Mt0/wDYjtIlnd3KPG0LRsyv BKHAYFSrBSRk4weQC2dcaVZzW1zqOg2lzY+J7y9EU10CZZ7aQ4D+YX3KYVjG4RnCNtTZtYoR2Vnp 9rYaba6fbQhLW1jSKGMkttVAAoyck4wOTzxXKqnI7jtc5G9n1fxTrFzbW63WnxWEEN3DEt1JBJdL I0qlZNpGzIiyo5K8bupUbXhux06NJ7+zkvZJ59sVwb24eWWMxlsRtuJ2lS7ce+eRil0T974r8Rz/ ANx7e2/75i8z/wBq1a1LT54bo6rpag3YUCa3ztW6QdAT0Dj+FvwPByN5wlUgmtxbM0q4u88PQzX8 2maLf6rbTPI09zJDfyrFa+Yxc4UNjexJIXoM5PGA2udbOrbLTRHzcuP30jp/x5ryDvU/x5BAQ85B J4BrZ0/T4NMs1trcNtBLM7nLyMeSzHuxPJNZ0KUr8z0G2ef/ABXjEOm+H4gzsEu2UM7FmOIX5JPJ PvXlsX/Ieu/+vaD/ANClr1b4uD/QtDPb7awz7+S9cL4Z8I33ijWNUks763tRbwwI3nQs+7JkPGGG K9KDtG7Ki7I5W88O/bdSkupLrKPLCxiaPcPLTOY+v3WOCe2R0NRx+GpIILMw3+29tmlY3DQ7vMMg ILMM8sOMEk9OQa9W/wCFU61/0G9P/wDAR/8A4uj/AIVTrX/Qb0//AMBH/wDi6fNAfNE8nk8KpmGO 3u2ito7c2+xo97AM2XZSThWYEjOOh+mGHwfC6GGS5ZrZpmkKBPmxs2xrvJJ+QZx2Oelet/8ACqda /wCg3p//AICP/wDF0f8ACqda/wCg3p//AICP/wDF0uaAXieX6foMmmwoILtUm8yPzpBGT5saDAQh mOPqMY9KhtPDUlm0Wy/ylrFKlpmHmJnJO8nOGIBxjAHsK9W/4VTrX/Qb0/8A8BH/APi6P+FU61/0 G9P/APAR/wD4unzQDmieUy+GpLu6kkvb/wA+OZYlmXycMwQfdDZ+VWb5iAPx70W3haKOJYJ7p5YI YpYrdQoUxiTO4k87mwcdAOOlerf8Kp1r/oN6f/4CP/8AF0f8Kp1r/oN6f/4CP/8AF0uaAc0TyKPw gEERF7tkRSC6o/zEJsjbBc4ZMkgjHtiiTwqkWm3kO95zLBFDGIo1Vk2YJxubGGb5iMjv35r13/hV Otf9BvT/APwEf/4uj/hVOtf9BvT/APwEf/4ujmgF4nlemabqQae8uJ1t7u4uxJLhA2+FRhUIyQv1 BJ9zUaeGZYrW3tl1FvJtJlmtkMIwGDlsvzluGxwVHtXrH/Cqda/6Den/APgI/wD8XR/wqnWv+g3p /wD4CP8A/F0c0A5onlL+GN0cIW+cSK0s0rlP9ZM64EmAQFKnkY6frVnSNCTSp5JfNWUmGOJB5e3Y FHzY5P3m+Yj19a9N/wCFU61/0G9P/wDAR/8A4uj/AIVTrX/Qb0//AMBH/wDi6fNAOaJx1j/yHdF/ 7Clp/wCj0r6JrzbRPhfcWmsWt7qmqwXEVrKs6QwW5TdIpypLFjwCAcAc4HPr6TWc5JvQibu9Aooo qCQooooAKQkKpZiAAMkntWL4p8TWnhbR2vrhTLIx8uCBTgyyEcDPYcEk9gD16HwrX/EereJ5mbVL tmtycrZxErAvp8v8R92z7Y6VzYjFQofFud2Dy+rin7miXU9n1L4jeFNLcxyatHcTDIMdmrTkH0JQ EL+JFef6p8UDHrc2oeHtKn/0mBYpxfBVVmQnY4CvnoxBzgkBfSuN0pbNdUslvQBYidPPAz/q9w3f d56Z6c10cFrql5fW0PiDzzYlnaBGAIdhGxVIACMoxCriMhTlBkEoa4JY6dVWjFfn9+x639jUaX8S TfXt929yA/EnxRdE/bQFU/wWF0tup+u6GRh+Dj61JaeN4LW6iu5fCUF9dwtviuLzWJpmjb1XzI32 n6YrXitba0ttSS2tZ7XdEWkhmTyyjfZb0fcLuyggKcM2TnPQiq9nosVj4gS6S38uH+37VLJi5O6B nkIZQTkqQqYbocHBPNKNWsrWt9w/qWC191/ebFt8Zwf+Pzw5Mnr9mu1k/wDQglblh8WPC13tW4mu tPdjjbd27AD6um5R+JrjtJ8O6XeWll5tq2d1q5lBO2cPLGjqH3/MB5hBCxgowALEjL8TcyRSXDNB D5MXAVNxYgAY5J6k9TwBknAA4FPHVqaTmk7hHKcLWbVNyVvSx9L2WoWWpWy3NhdwXUDdJYJA6n8Q cVYr5es57jTbv7Xp1zNZ3PeW3fYW9m7MPYgivWPCXxOiu7aS018pHfRJmKSJf+PvttVf+enT5R1z kdwOvD42nWfLszzcZlVbDLn3j3/zO31jU20+GOO3jE9/ct5dtATjc3cseyKOSfTgZJALPDGoz6v4 T0bU7kILi8sYLiUIMLudAxwPTJrJuJbjRtF1bxTqMAm1CGzln+zh8CKNFLiFWwcZx8zYOT7BQKM2 gw6E2h6Xa6nrS21zP9iiRL7AgRIJJBgbTkYiC4985450+sRu+x5tjuaK8s0+TWda+yf2VLfP52lW moyfatceLZ5/mYQbYH3Y8s88dRxWpIkbeFLPXbbV/EDpfJbG2ilvQh3XDIkYcgHaN0i7iN2BnAbo adeKCxpeLtWXf/Yk0F3FaXMRNzfCxkmjVDxsUqjLv92wBwfm6VU0LxjFNdXaXk0KaWLpraxvWcgM VRSUkLH75ySCeuCOCOahgvdO0/VrrXLvXLf+zrU3jGz1Ezxyx4clUdo48yDyzlcYAZDn5uNTQdK0 7VPCl1azwzSLc3M6XYnm81vPjkMbsr4BIDR5VsA4AOAeBhWnGWo0bepSJLod68bq6m3kwynIPymo 9CuIbXwdpc9xNHDDHYQs8kjBVUbBySeBXFalb+FfD+lXq63odkNRt1ARrWIW7X6sdqMpTHOcBh/C eehXPAXQ1rxWI5rny5IIcR21qJFjiQgcJDGxy7AEDjc3I9QKl1YYdd2zswuCniXdO0Vu2eqan8WP DNiSlpJc6nIDjFlFlf8AvtiqkfQmuauvjJqDsRZaBBGvZri7JJ+qquB/30a4weHNWKRv9k4kRZR+ 8TIjYAiQjORHg8uflByCQQRUUei30lxND5cUZixveWdI4/mGVw7EKdw5GDyASMjmuSePrv4Y2+R7 dLKMHFe/Pm+aX9fedK3xZ8Ws2Uj0RB/dNpK36+aP5VGvxU8XqSQ+kNns9nJgfTEorDHhvWGjRxYS 5k3eXHx5jlWKsFTO5ipU5AGVHJwCDTRoOoGVkKQKqqG85rmNYiDkDEhbYxyrcAk/K3904y+t4rv+ H/AOlZdl/Zf+BP8AzOnt/i54mjb/AEiy0i4H/TNJIf5s9bNl8ZoTxqWgXMX+1aTrMPrhth/LP41w kfhy/m09bmOJvM+0y2zwuAhV0CEKNxG5zvICAbjtOAecM/sSVtIhvY/NeSZ4kjhEYJcu0yjbgknm HGCAST04BNxxuJW+vyMp5XgZLR26aP8Azue4aJ428O+IJBDp+pRm5P8Ay7SgxS++FYAn6jIroK+a pfDt5I6xPDbyIQX80XETRLgjOZA2xSCy9SDll/vDPZeEvHeoeHr9NG8QSTXFmxCRStmWSJmxsG4Z 8xGyMHnqDkr07aGNU3yzVmeTi8qdKLnSkpJffY9T1fUxptsnlxefeTt5Vtbg4Mj4zyeygAknsATz 0rkdH1Ow8M+JNdi1zWI1urgwTNJO20SMUOdgPRR0A7ADOTknd0JDqQXxBclWmu4h9nRWDLbwHkIC ONx4LEdTgdFFchfeI9Yh8BeJvL0vWJXhfVli1OO4gCxhZpwrAmYSAIABwuRt+UHitXXfPpseVY7D /hOfC3/Qesf+/oo/4Tnwt/0HrH/v6K5PW7q8l1ie1zqt1CfEiwfZrC9MEjR/2WJNit5iYXf85G4A kHqTz1fhi3vreyuRdx3UMDXBa0t7y48+eGLYgKySbn3EyCRh87YVlGRjaB4iyvYVhf8AhOfC3/Qe sf8Av6KwdS1G18SeMNIbw/q0UlzZ2d3KHicsisWgCrIB1VhuGPxHIBEPh57iG+0SS7l1WO5u/lmv XvRdWWpuYXdhCgmYRKxUyqwjTCpt+XdtJ4H8Tz6trUgnmvpIdTtW1C1W4tZYljUTEYBdQp/cy2q/ uyy7kds5bc5Ku2nZDsT6Jr+Lq+v77StXfU3YQXYhtC8cGzJWJQhJYDeTuwS27PCkAXrn4g6FY3CW 98NTtZnRpEjl0y43MqjLMAEJwByTT/Fc03h6xvPE9h5Pn21uftEMz7EuUGdoJ7OpPy+uSvcEeJxX 0lxrP9pajc3L3Mj+ZJcxHEit/Cy+ynBC5HAwCvUclerTjFSe7O/A4GWKcrOyR148eayLzVn8NWkE 0N/fGVZ5YpGlwEihH7khSucIATkEnAGQRWRf6v47vL1LK81DWUupBvjtoIfs7FeegRQxHB7noaJ9 etVtrxIJLmW6uLVoGvGhWB5N0kbFXCsd3CSZcks2/B4GasP4lsZbm7JSdEuLy6nDtCkoRZWiZcxs drn92QQ3AJDDJUVhLEylpz29D2qOX06aX7u/m7/fb/gXOeFhrF5dSRf8Te5uRJskVpppH8zB4OST uwh684U+lNTQdRfUZLdLDUGv413SIqyGZV45P8QHI/MV0q+LLVdUNzHHcxQvdafK8ahRlIEIZSF2 qfm2kDAHHReBVBdVsLnRLfS7prmFI0QtNFEsh3rJOwAUsvBE/XPBXGDnNYud/tvr1OtUrf8ALpLb p33+7sZN1ot4+mQ3LteS2joLgtHPKVi+d41LEHCklGx9fqK2tKTxb4Ym+x6Fe3Uhn3zvDHbeeW2y NES4dN45T2IBA46Czf8Aii0viLkpdpcJFdotuWDRZuGlyQcgqVWQc4O7aBhcZM914tsbuW4QLLDF K5k8ySyiuSD51w4GxzjlZx82cgqRyDmtI1nHao/v/wAzGph1Na0V16f5avvp6GzpHxS11LRrrVtA +12EbbZb2wVk2Hjgq2VJ5H8Y6jjmvQdB8TaT4ltmm0u7Evl4EkbKUkjJ/vKeR356HHGa8Tm123ur W6eaS7N1K0pRSiEqXZiSJl2lVw7Bo9pVssflLAri2N/d6TqEOpafL5V5ByjdmHdW9VPcf1wa3p5g 4tKeq7nHWyVTjKVL3WunT+vM+naKo6NqK6xoWn6mkZjW8to7gIeqh1DY/Wr1eufNhRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAebfF/Rrq807T9XgBeHTjL9oQclUcL+8+i7OfQMT0Brym1 t5b26gtrdd8s7rHGuQNzMcAZPHU19P8AUYNcBrfwp0i/vPtenSSae5cNLbx48mQZ5ABHyE+o4HXa a8/F4N1pc8dz2stzRYaDpTWnfseUz6WEQNaX1tfYzvW3EgZAAWJKuqkjCsSQCBjnGRltxo+p2ksM Vzp13DJO22JJIGUyHgYUEcnkdPUV6HqXh7XtEnSeO3vtauVimA1GBI45Yy0LoB/rPMk+ZkOTygTC 9a5h9cXTWf7fpmqWgZbVCbizeML5ds8LEhsBhucEKflccHANcEsHKO6a/r5/mexTzKEvhkn6vV/l +X+ZgHTL9bt7RrG5Fym3dCYm3ruIC5XGRksoHruHrT30fU472OyfTrtbuRdyQGBg7DnkLjJHB/I1 oXfjTSbiKZLK7CMdM+w7k8qIEm48xjtjICqyZBAzycHdyxkuvGGiXS6lDLctFBe3V1K0o2M0aSPC 6/LuAJzCQRkY3ZycYrJ0I+ZusVPS9v66/wDAM06Lf/ZDcC2lbY8ySxqjF4vKCFy4x8oHmDk++cU9 tDvvLtWhia4e5YrHFFG5ckRpIflKg42yDkcHBI4wTsWvi7TLv7CtqNQuDYXSXESWqeYk/lRQxoHV SdpbymORu2ZIAfORuaZHrOowQ21v4c1SONoRDLPd2cQWMCO1Xd5U7Lv+a3YY7BgRyMVrHCc2yZzz zHktzNL5/wBM88likgleKVGjkRiro4wVI4II7Gt3wVomp614mt59MkWE6exne4kXcitsYKhHfcTy OoXJyDiu4X4WT6nq8l5reqYgwiLBaRqjOqqFGWAAQYX7qrx03nGT6Dpml2OjWEdlp1rHbW0f3UjH fuSepJ7k8murDYBxnzz6Hn4/OIVaTpU1vu/8jD1DzPFXg3WdOhVba/ntJ7KSGZuIJmjK4Ygfd+YE EDlSCOtZUmjeEbPWtGv9Ij8O6fLZXbyTvAIonaMwSx7QVHPzOhwcDj1ArotXsp4LldZ06MyXUabL i3Xj7VEOdv8AvrklSfUrwGyM7wboGnp4H8PrdaRai5Gm24lEtsu8P5a53ZGc5znNdaw7u1fQ8C5z 2j+HPDifYv7fk8Oal9l0Wx09POaObZJD5vmFd44U70x3OOQMCun1vUrC+0ie2tdW0oyPtzHcSxtH MgYF4nznCuoZCcHAbIBIxWr/AGDo/wD0CbH/AMB0/wAKP7B0f/oE2P8A4Dp/hTeHu7tiuefxaRYz JJbvc6Bo+m3NxbPPYaVf7VUQs8oljdVj2yvJ5Kt8oISPhs7dvU+HdMt9Jn1OaxvFuNLu2S4Est29 xIJgvlyZkcklNscWMkkHf22ga/8AYOj/APQJsf8AwHT/AArlNI0ie81LWdLeya00VNReWQbNi3QK JtjUf3OMseh4XkFqUqD6Mdyp4p8PXnjzRn1C2OxbY+ZpcLYH2j+87E9A44Qdhhj1wvnek6la2UEt rqEc+Y5SZLOW2R93ADJl8NAxxguuT93j5Rn6K6DArnvEfgnRPE/7y+t2juwu1bu3bZKo9M9GHswI 9qithFNJwdmjvwWP+rpwmrxf3o8Wn1e3k+3bUl/0jTra0XIHDx+TuJ56fumx9R+E8Wtaf9reeW3Y sLa2jRmgjlJ8uJUdNr5VQxAIfBKhfunJFb2pfCHWrZi2l6laXsf9y5UwOB9V3Bj+C1zV14M8V2Wf O8PXbAfxW7RzA/QKxP5gV5s8NiYO/Lf+n/mfQU8bgaitzW9dO3y6FzUfEVpd62b2OOcR/Zr2LDKM 5macr36DzVz9D17wLqthc6Jb6XdNcwpGiFpoolkO9ZJ2ACll4In654K4wc5rIfTdVi/1uiaxHzjL 6dMBn67cGmfY77/oGal/4BS//E1m4176xf3M3U8JZJVFp5rz/wAzpE8R2Et3HfXEFylzDqs2pRpH tZDuMZEZJweSn3u391s8RWviO3tNP0uNYJXmsp7eYg4VW8uW4cjPJGRMo6dj7ZyYdD164bbD4e1g n/bsZIx+bgCtmz+HPi+9P/ILhs17NeXSj9I95/PFXGniZO6iZTr4GEbOat6379vUR9ftTLDELmf7 OqyZZdNto0y2zgwD5ZB+7HLN12kAbPmTRNCPjDxYq2EDRafDLHJdTbNqjbtJwB8qu5GQgOFDcZCj PYaR8HbZHWTXNTkux1NvaqYU+hbJY/gVr0aw0+z0uzjs7C2itraMYSKJQqj8BXdRwc7qVV7dDycV mlPlcMOt1a+2/l/XoY1wv/CN37XS8aRdSZnXtaysf9Z7IxPzejHd0LEZ93LCRqvhqy8OXd/aMshv BHcpGrG4Lu4Bdw3Jdjx0zxjFdhJGk0TxSorxuCrIwyGB6gjuKwvD3h2XQr7U5Ddme3uGjFur5LxR ouArN/FjOAeuAM5OSeyVCLlc8O5l7bv7b9s/4Qu++0favtm/7dB/rvJ8jdjzcf6v5cdO+M81of2z rf8A0Kd9/wCBdt/8cro6KX1eAXPPToatFNC/gnVZLeSJ4RbyaurQxI6lCIozNti+RmUbAuFJAwDi tlNS+3a9p9pq2h3NlcRLLe2kks8bKGRfKc/I552zkcjHJ7gV1Nc/rvhttc1rTbl7ny7O3hniuYQP mnWQxnZnsp8vn1Bx3olQi1oFyBLKHxez3F9EJdECsltA/S5yCDM3+zgkJ+Ld1x5N4q8Ean4WmklE ct5pWSY7qNSxjX0lA6Ef3vun2JxXv6qFUKoAUDAA7UtTUwtOpDkfQ6sJjKuFnzU+u6PlpHWRQyMG U9CDkGpraf7Ndw3HlRS+U6v5cq7kfBzhh3B7ivd9X+HnhfWZHmm0xILlySZ7RjC5J7nbgMf94GuV vPgxCf8AkHeIbqL2u7dJv/QdledPLKid4NM9+nntGStUi1+Jycem6ZbXMccsym01O5ijgldl3Q2x ZWaQnGFcZVNwyMrMO1WNCjXU9XSDUdPtoEtLq3RI1t1jwxnRDC/GXym84fLfuyc/ezpXPwk8RlUW PWdPuFjXbGJUkjwMk4HLYGST9SaH+G/jmT7Nv1jT2+y4+z7ruc+TjGNnyfL0HT0FCwlZP4fyB5jh pR/ia+j/AK1WjMgtZW/hzT/tDWOyaxmZoBbf6RJL5kqo4k2cAEJkbxwhGDnB5avQY/hH4hnWNLrW 7CNUXaoWKSXYMk4AJXjJJ7ck+tadn8GLYf8AIR1+8m9rWFIQf++t5/WpeBrztdJFRzfC0rtNu77f 8MeUvIkSF5HVFHUscAV1vhPwDqHiWaOe8gltNHyC8koKPOv91FPOD/eOODxnt6ro/gLw1ocqT2ul xvcocrcXJM0in1BfO3/gOK6Suqhl0YPmm7nn4vO6lWLhSXKn16/8AZFFHBCkMSKkcahUVRgKBwAK fRRXpHhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV5V44+OWi+GLifTtNt5NS1OIlHUgxxR N/tMRk/QDHuK9VrxXxjDrmu6NaL4h+Fb6pemA+deWl3FBJFIA7lYwjSsVCrgFj8zYG0EhSAcz4P+ Ptxb6tqV54uN5cxTIi2tvYQp5cOCd3DMOuRySTxXYf8ADR3g/wD6Buuf9+If/jtcT4b8A+KPDPib VdOHgLT9WWWF5bebVGSeBVQSBdsm0Dez7PlIViByFB3r6NH4SupV19D4C8KQyRyqmkPJpcBSVTK6 5k2y5KiMRsThGG5sI5UBgDP/AOGjvB//AEDdc/78Q/8Ax2j/AIaO8H/9A3XP+/EP/wAdqnpPh/xb NDdHU/hX4KhdUcw7LaDLMIZSo27yCDKsKk7lwGPByWTUutDv4tFk+z/CDw5PqaxW4Q/6KsbSPCWl baRkLHIAm3dlgchuM0AU5f2hvBM5Bl0jWZMdN9tCcf8AkSmr+0F4FRgy6JqysDkEWkAI/wDIlWls ZLm31q2h+DWjQ6pZ28L2u+OBreaSQAlfMZEDFASTtyCUYbhlS1fWdO1DRLe4ux8IfD+pwR6ncIqW lrD5jWYCiFgoDsXZmJOBwEOVGcgAk/4aO8H/APQN1z/vxD/8do/4aO8H/wDQN1z/AL8Q/wDx2tCL w7NFq2oRXXwq8OT2KxTvYzW0dspd0kk8tJA33d6CPkBtpOT1KxxjSpToz3B+CWjDUFuFQWhnstrR FSTIJNvUMACpA+8CCeQACn/w0d4P/wCgbrn/AH4h/wDjtH/DR3g//oG65/34h/8AjtakGhY8QRWN 58H/AA+NPLhZNRtJrWVVBH3gjxo5AJweAeCQG4z1n/CCeD/+hU0P/wAF0P8A8TQB5/8A8NHeD/8A oG65/wB+If8A47R/w0d4P/6Buuf9+If/AI7XoH/CCeD/APoVND/8F0P/AMTR/wAIJ4P/AOhU0P8A 8F0P/wATQB5//wANHeD/APoG65/34h/+O0f8NHeD/wDoG65/34h/+O16B/wgng//AKFTQ/8AwXQ/ /E0f8IJ4P/6FTQ//AAXQ/wDxNAHn/wDw0d4P/wCgbrn/AH4h/wDjtH/DR3g//oG65/34h/8Ajteg f8IJ4P8A+hU0P/wXQ/8AxNH/AAgng/8A6FTQ/wDwXQ//ABNAHn//AA0d4P8A+gbrn/fiH/47R/w0 d4P/AOgbrn/fiH/47XoH/CCeD/8AoVND/wDBdD/8TR/wgng//oVND/8ABdD/APE0Aef/APDR3g// AKBuuf8AfiH/AOO0f8NHeD/+gbrn/fiH/wCO16B/wgng/wD6FTQ//BdD/wDE0f8ACCeD/wDoVND/ APBdD/8AE0Aef/8ADR3g/wD6Buuf9+If/jtH/DR3g/8A6Buuf9+If/jtegf8IJ4P/wChU0P/AMF0 P/xNH/CCeD/+hU0P/wAF0P8A8TQB5/8A8NHeD/8AoG65/wB+If8A47R/w0d4P/6Buuf9+If/AI7W p4++G+lX2m6cmieEtNZ0vQ9ytraxxsYvKkHOJYSRvKcCQdAecYPnl/4COkWsaz+H4LO6i8P6pcX0 lw0M6zIkSCAR7RgTRF4g0gSPcwcgtkkgHX/8NHeD/wDoG65/34h/+O0f8NHeD/8AoG65/wB+If8A 47XGR+CL60s/Edi3hbRtN1A3GlLYvcfvfLSS6kRZSGe4wWYKrpuxtB+9jDSeHtG0y88R6FpMug6G NSWWG2keSaGR4/s6bbqGW2VsFmMNw6zssmfMjGVJDRgHX/8ADR3g/wD6Buuf9+If/jtH/DR3g/8A 6Buuf9+If/jtcRqfgW48V6np+oaT4VsbD+2Nl/bWjEKiW6R2qvvMcyqIWaZ2+VPN+UcDcdtfTbLR NCs9LudW0DSjcSRJq4mubmKMRWDnf5CQO7faZH2XCKW3MoeEllPCAHf/APDR3g//AKBuuf8AfiH/ AOO0f8NHeD/+gbrn/fiH/wCO1xnhz4QardW1/bXel6MbqC9topI5ZJGSIrYySMHZXD4Z5oN3lsRu BIUqoB09G+D8qXGk2+r+GPtFqsSxTzMED/8AH1OSz+Xdptbymh5AmxgAfdwQDoP+GjvB/wD0Ddc/ 78Q//HaP+GjvB/8A0Ddc/wC/EP8A8do0H4Zmxn0BrjwppTWdraQQ38dwkMs0sroxncZDB18x4juZ wyiBwilXw+XovwXaDRnj1HSbQ3cqWK/uVU7FZXjuWLSSP+9RZnf5MJuhhZQxygANT/ho7wf/ANA3 XP8AvxD/APHaP+GjvB//AEDdc/78Q/8Ax2vQP+EE8H/9Cpof/guh/wDiaP8AhBPB/wD0Kmh/+C6H /wCJoA8//wCGjvB//QN1z/vxD/8AHaP+GjvB/wD0Ddc/78Q//Ha9A/4QTwf/ANCpof8A4Lof/iaP +EE8H/8AQqaH/wCC6H/4mgDz/wD4aO8H/wDQN1z/AL8Q/wDx2j/ho7wf/wBA3XP+/EP/AMdr0D/h BPB//QqaH/4Lof8A4mj/AIQTwf8A9Cpof/guh/8AiaAPP/8Aho7wf/0Ddc/78Q//AB2j/ho7wf8A 9A3XP+/EP/x2vQP+EE8H/wDQqaH/AOC6H/4mj/hBPB//AEKmh/8Aguh/+JoA8/8A+GjvB/8A0Ddc /wC/EP8A8do/4aO8H/8AQN1z/vxD/wDHa9A/4QTwf/0Kmh/+C6H/AOJrl/GOmaJ4agjk0z4WWOuM 8TyMtpYRDYVeJQDiMnkSMeAT8h4xuZQDH/4aO8H/APQN1z/vxD/8do/4aO8H/wDQN1z/AL8Q/wDx 2rFk/hq58q3k+HWhpqT6hFbmyFiwkNq+wNdBHtlcRqzEEuqLlGG/OATQ5vDF9Lu1z4YWPhyxFobh 73U7GGOFTujjCFigwxdpAA20lVRsfPhQCv8A8NHeD/8AoG65/wB+If8A47R/w0d4P/6Buuf9+If/ AI7RJc6Nb2LzzfCCB5PsjSww22jvI0svnSRqnNsuxdqCQs+1grrhGNWLkaPbz3MCfCCCZo5b1Y5I 9MTy3WBHZCSYshpCqBQAykSDDsysgAK//DR3g/8A6Buuf9+If/jtH/DR3g//AKBuuf8AfiH/AOO0 f2h4YSW+hvPhRBp01vFcGH7dp0MaXk6NiG3hcKRJJIMnC56fLvHNWEvfBVxFa+V8N4ILqS7Ec9je 6MqXUVvtJNyIY45HaPcAgOACxwSOtAFf/ho7wf8A9A3XP+/EP/x2j/ho7wf/ANA3XP8AvxD/APHa ktNT8Gulh9v+E93YmdFN1NN4ejW3sjuIYySuqjYoG4vjG0gnByBoT2fh7+0pYbL4Zabd2P8AZhvo b+OyhaKZvN2KoKIwIKYl+Us+w8RlvloAy/8Aho7wf/0Ddc/78Q//AB2j/ho7wf8A9A3XP+/EP/x2 i48iHSY5o/gpYz376h9ia2jt4giDy1beZGhHy7mKbgpj+Rjvxt3SalqPg3T4b+JPhjHealZ3CWXk WujRsk1y0LylY2ZAzIoTl9mcMrBSCKAI/wDho7wf/wBA3XP+/EP/AMdo/wCGjvB//QN1z/vxD/8A Ha2Dp/huS2gmtvhxpU6vqp09yljGwVVuZYGkG2NiNojDneEXDYDkjFdR/wAIJ4P/AOhU0P8A8F0P /wATQB4h4y+Ps11qWl3fhBry1SASC6gv4U8ufJXbwrHphuQQeetdv4I+Oui+JZ4NO1W3k03UpSET AMkMrexHK/QjHuam8afBbSfFGpaUdPjsdFsrcSfahZWiJJMSV2gYAHGG5OcZ6V13hbwH4c8HQBNH 06OOYjD3MnzzP9WP8hge1AHSUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFY+t+G7PXvN+1STp5mn3OnnymA/dz7N55B+YeWuD05OQaKKAI9W8L22rTXc 7Xd3bz3CWi+ZAUzGbaZpo2UMrDO5znIIIA4FSWfh9LHUWuIdQvhamWSdLDeohSWQsztkKHbLO52s zKC2QBtXaUUAGm+G7PS/7I8iSdv7K09tPg3sDujPlZLYAy37leRgcnjpinD4NtrW3soLLUtStEt7 KGwlMMiBrmCIEIrsUJUjc/zRlG+c88LgooA1LHSUsNT1S9juZ3/tGVJpIX27I3WNY8rhQ3Komck9 OMZOdCiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooA//9kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwEAAEQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAGwAAAHMAdABlAHYAZQBuAC4AYwAuAHYAZQBu AGUAbQBhAEAAYgBvAGUAaQBuAGcALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQtcAAAAbQBhAGkA bAB0AG8AOgBzAHQAZQB2AGUAbgAuAGMALgB2AGUAbgBlAG0AYQBAAGIAbwBlAGkAbgBnAC4AYwBv AG0AAAB5WIH0Ox1/SK8sgl3EhSdjAAAAAKWrAABdAQAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kL AgAAABcAAAA0AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAG8AcABlAG4AZwByAG8AdQBwAC4AbwBy AGcALwBiAG8AbwBrAHMAdABvAHIAZQAvAGMAYQB0AGEAbABvAGcALwBlADAANAAxAC4AaAB0AG0A AADgyep5+brOEYyCAKoAS6kLgAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBvAHAAZQBuAGcAcgBv AHUAcAAuAG8AcgBnAC8AYgBvAG8AawBzAHQAbwByAGUALwBjAGEAdABhAGwAbwBnAC8AZQAwADQA MQAuAGgAdABtAAAAeViB9Dsdf0ivLIJdxIUnYwAAAAClqwAAkAAAAEQAZAAAAAAAAAACAAAAAAAA AAAAAAAAACAcGBWjAqMCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwRAAAALIE CvAIAAAAAQQAAAAKAAAzAAvwEgAAAH8AQAFAAQABEAD//wEB8P8AABMAIvEGAAAAPwUBAAEAAAAQ 8AQAAAAAAACAkAAAAEQAZAAAAAAAAAACAAAAAAAAAAAAAAAAACAcGBXVAtUCAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwRAAAALIECvAIAAAAAgQAAAAKAAAzAAvwEgAAAH8AQAFA AQABEAD//wEB8P8AABMAIvEGAAAAPwUBAAEAAAAQ8AQAAAABAACAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCEQASAAEAnAAPAAQA AAADAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEwAAEDx/wIATAAMAAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAkAENKGABPSgIA UUoCAF9IAQRhShgAbUgJBG5IEQRzSAkEdEgRBAAAAAAAAAAAAAAAAAAAAAAAAEQAQUDy/6EARAAM AQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAA AABWAGkA8/+zAFYADAEAAAAAAAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX 9gMAADTWBgABBQMAADTWBgABCgNsAGH2AwAAAgALAAAAKABrAPT/wQAoAAABAAAAAAAAAAAHAE4A bwAgAEwAaQBzAHQAAAACAAwAAAAAACQATEABAAIAJAAMBAAA/TrlAAAABABEAGEAdABlAAAAAgAP AAAANgBVQKIAAQE2AAwEAAAXNJUAAAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAADAA+KgFCKgJwaAAA /wAAAAAAxhQAAAgAACgAAAAA/////wAAAAAvAAAAWwAAAIIAAACwAAAAEQEAABIBAAAaAQAAGwEA AKsCAACsAgAAIQUAACIFAADlBgAA5gYAAAMHAAAEBwAApAcAAKUHAABECQAARQkAALQJAAC1CQAA 0gkAANMJAABgCwAAYQsAAKYLAAAPDAAAPwwAAHwMAADCDAAAwwwAAJMNAACUDQAAmREAAJoRAADI FAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAEgADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAABIAAwAQAAAAAAAIAAAACAAAAAAAAAAAAAAJgAASAAMAIAAAAA AACAAAAAgAAAAAAAAAAAAACYAAEgADADAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAABIAAwBAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAAAAAAAvAAAAWwAAAIIAAAAaAQAAGwEAAKsCAACsAgAA5gYAAAMHAAAEBwAA pAcAAKUHAABECQAAyBQAAIiQADAAMAAAAAAAAAIAAAANAAAAAAAAAAAAAAGKkAAwADAAAAAAAAAB AAAAAwAAAAAAAAAAAAAHitAAMAAwAAAAAAAAAQAAAAQAAAAAAAAAAAAAB4qQADAAMAAAAAAAAAEA AAADAAAAAAAAAAAAAAeIkAAwADAAAAAAAAACAAAAAQAAAAAAAAAAAAABAwAAAAIwAAAEAAAAHAAA AAAAAAAAAAAAAAAAB4iQADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGIkAAwBTAAAAAAAAABAAAA BAAAAAYAAADUUlAHitAAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACAB4iQADAGMAAAAAAAAAIAAAAB AAAAAAAAAAAAAAGIkAAwCDAAAAAAAAABAAAAAwAAAAAAAAAAAAABiJAAMAgwAAAAAAAAAgAAAAEA AAAAAAAAAAAAAQAAAAABMAAAAAAAAAAAAAC4FwAAAAAAAAAAgAGKkAAwADAAAAAAAAABAAAAAAAA AAAAAAC4F7YHAAYAAP8OAADGHAAADwAAABIAAAAABgAAYBMAAMYcAAAQAAAAEwAAAAAGAADGHAAA EQAAAMIAAADzAAAADgEAAPkCAAA8AwAAcAMAAOYGAAD+BgAAAQcAALUJAADNCQAA0AkAAMYUAAAT WBT/FYATWBT/FYCTXxT/FZyTXxT/FZwPAADwxAAAAAAABvAYAAAAAggAAAIAAAAEAAAAAQAAAAEA AAAFAAAAPwAB8IQAAABSAAfwJAAAAAUFMZ6VVKmxDTbb+zb/ImOhm/8A6nIAAAEAAAAuKAAAAAAA AFIAB/AkAAAABQVOA9OWVuUeaSF22qMy8PXn/wAPvwAAAAAAAP////8AAAAAUgAH8CQAAAAFBQ38 ssPp+oBK9oxLcY1rhQH/AJ3DAAABAAAAGJsAAAAAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAA DwAC8GYBAAAQAAjwCAAAAAMAAAAEBAAADwAD8AQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAA AAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwYgAAALIECvAIAAAABAQAAAAKAAAzAAvwEgAAAH8A QAFAAQRBAwAAAL8DAAAgAEMAIvEYAAAAkAMDAAAAkgMDAAAAvwMAAgACPwUBAAEAAAAQ8AQAAAAB AAAAAAAR8AQAAAABAAAADwAE8GIAAACyBArwCAAAAAIEAAAACgAAMwAL8BIAAAB/AEABQAEEQQEA AAC/AwAAIABDACLxGAAAAJADAwAAAJIDAwAAAL8DAAIAAj8FAQABAAAAEPAEAAAAAAAAAAAAEfAE AAAAAQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgA BAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA/wYAAM4JAADGFAAAAgQAAAAAAAAAAAAA/BIAAD0OAAB0 gAAAAAAEBAAAAAAAAAAAAABkFAAASw8AAHSAAAAAAP//BwAAAAYAIL5WAAgAAgBsS+kMBgAhvlYA CAACACw36QwGACK+VgARAAEAbDfpDAYAI75WABEAAQAsP+kMBgAkvlYAEQABAGxC6QwGACW+VgAQ AAEA7DvpDAYAJr5WABEAAQDsSekMQAAAAI0AAABtCAAAdwgAAI0IAACNCAAAlggAAMgUAAAAAAAA AQABAAAAAQACAAAAAQADAAAAAQAEAAAAAgAFAAAAAgAGAAAAAgBZAAAAkgAAAHUIAACBCAAAlAgA AKAIAACgCAAAyBQAAAAAAAABAAAAAgAAAAMAAAAEAAEABQAAAAYAAAAEAAAAOQAAAAQAAAAqgHVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWAU3RhdGUAgD4AAAAHAAAA KoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MKgFBlcnNvbk5hbWUA gDgAAAAFAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MEgENp dHkAgDkAAAACAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MF gHBsYWNlAIAMAAAB/Fg5DgAAAAAHAAAAAAAHAAAAAAAFAAAAAAAEAAAAAAAFAAAAAAACAAAAAAAE AAAAAAAAAAAABwAAAA0AAAAvAAAANAAAAJQAAACvAAAAsAAAAMIAAAD0AAAADgEAAHgBAAB+AQAA oAEAAKYBAABCAgAASAIAAKEJAACnCQAAZAoAAGoKAACxCgAAuQoAAAgMAAANDAAAFwwAAB8MAABz DAAAewwAAAgOAAAODgAAehAAAIMQAABVEgAAWxIAAOISAADrEgAAkxMAAJsTAADIFAAABwAcAAcA HAAHAAQABwAFAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAAAAAAI0AAACvAAAAsAAAABABAADIFAAABwAEAAcABQAHAAAAAACNAAAA rwAAABIBAAAbAQAAPwsAAGALAADIFAAABwAEAAcABQAHAAUABwAAAAAAlAAAAK8AAADIFAAABwAE AAcAAQBtRxpMCt5m3P8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAIAAAAuAAEAAAAEgAEAAAAAAAAAAAAAAAAA AAAAAAoYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP6HaAAAAACISAAAAgABAC4AAQAAAAKCAQAA AAAAAAAAAAAAAAAAAAAAChgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/4doAAAAAIhIAAACAAIA LgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+h2gA AAAAiEgAAAIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhBAOEYSY/hXGBQABEA4G XoQQDmCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E4BAR hEz/FcYFAAHgEAZehOAQYIRM/4doAAAAAIhIAAACAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAA AAAKGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+h2gAAAAAiEgAAAIABgAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAoYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP6HaAAAAACISAAAAgAHAC4A AQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/4doAAAA AIhIAAACAAgALgABAAAAbUcaTAAAAAAAAAAAAAAAAP///////wEAAAAAAP//AQAAABIADwAJBBkA CQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEFQAAAAQAAAAIAAAA5QAAAAAAAAAUAAAA+D4D ACNpDwAiBBsAPwFMABQVUABAbFcAbARZABAwWQAvCVsAk1ZmAPROlAAXNJUAUXyuAHk3tABzcrYA 0UK/APRtwAA2QtYA/TrlAOAf7wCcJ/EA/0ABgAEAlQAAAJUAAADAD7MLAQABAJUAAAAAAAAAlQAA AAAAAAACEAAAAAAAAADGFAAAgAAAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAA AAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABAAAAEcWkAEAAAICBgMFBAUC AwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAA ADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMm kAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAABdEZABgAoC AgYJBAIFCAMEAQAAAAAABwgQAAAAAAAAAAAAAgAAAAAATQBTACAATQBpAG4AYwBoAG8AAABBAHIA aQBhAGwAIABVAG4AaQBjAG8AZABlACAATQBTAAAAIgAEAHEIjBgA8NACAABoAQAAAADASbwGkqu8 pgAAAAADAAIAAAAZAwAArREAAAEACgAAAAQAAxAlAAAAGQMAAK0RAAABAAoAAAAlAAAAAAAAAHkF APAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0ALQAgYFyNAAAAAAAAAAAAAAAAAAA vBQAALwUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAAAAAAAAAAAATKDUQDwEAAI3AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABIWAAAAAAp8P8PAQABPwAA5AQAAP///3////9/////f////3////9/////f////3/9OuUAAAAA ADIAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAuAEIAbwBlAGkAbgBnACAAVgBvAFcATABBAE4A IABJAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AIABhAG4AZAAgAEQAZQBtAG8AbgBzAHQAcgBh AHQAaQBvAG4AAAAAAAAAEABSAGkAYwBoAGEAcgBkACAASAAuACAAUABhAGkAbgBlABAAUgBpAGMA aABhAHIAZAAgAEgALgAgAFAAYQBpAG4AZQAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAGAAAAAQAA AAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAsAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAANAAAAAEAAAA 3AAAAAUAAAD4AAAABgAAAAQBAAAHAAAAEAEAAAgAAAAkAQAACQAAAEABAAASAAAATAEAAAoAAABs AQAADAAAAHgBAAANAAAAhAEAAA4AAACQAQAADwAAAJgBAAAQAAAAoAEAABMAAACoAQAAAgAAAOQE AAAeAAAAMAAAAEJvZWluZyBWb1dMQU4gSW1wbGVtZW50YXRpb24gYW5kIERlbW9uc3RyYXRpb24A AB4AAAAEAAAAAAAAAB4AAAAUAAAAUmljaGFyZCBILiBQYWluZQAAAAAeAAAABAAAAAAAAAAeAAAA BAAAAAAAAAAeAAAADAAAAE5vcm1hbC5kb3QAAB4AAAAUAAAAUmljaGFyZCBILiBQYWluZQAAAAAe AAAABAAAADMAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAAjIZHAAAAAEAA AAAAmHgrdDrIAUAAAAAAXIdYH0TIAQMAAAABAAAAAwAAABkDAAADAAAArREAAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4b EJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a50AQAAMAEAAAwAAAABAAAAaAAAAA8AAABwAAAA BQAAAJQAAAAGAAAAnAAAABEAAACkAAAAFwAAAKwAAAALAAAAtAAAABAAAAC8AAAAEwAAAMQAAAAW AAAAzAAAAA0AAADUAAAADAAAAA8BAAACAAAA5AQAAB4AAAAcAAAAVGhlIEJvZWluZyBDb21wYW55 LCBNJkNUAAAAAAMAAAAlAAAAAwAAAAoAAAADAAAAvBQAAAMAAADEHwsACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAC8AAABCb2VpbmcgVm9XTEFOIEltcGxlbWVudGF0aW9u IGFuZCBEZW1vbnN0cmF0aW9uAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAGABAAAD AAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQE AABBAAAAGAEAAAwAAAADAAAAPgAyAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8AAAA0AAAAaAB0 AHQAcAA6AC8ALwB3AHcAdwAuAG8AcABlAG4AZwByAG8AdQBwAC4AbwByAGcALwBiAG8AbwBrAHMA dABvAHIAZQAvAGMAYQB0AGEAbABvAGcALwBlADAANAAxAC4AaAB0AG0AAAAfAAAAAQAAAAAAfhAD AAAAcgBYAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAAiAAAAbQBhAGkAbAB0AG8AOgBzAHQA ZQB2AGUAbgAuAGMALgB2AGUAbgBlAG0AYQBAAGIAbwBlAGkAbgBnAC4AYwBvAG0AAAAfAAAAAQAA AAAAfhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAA AEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAA UwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABh AAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8A AABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAA AH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAA jAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACa AAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgA AACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAA/v///7EAAACyAAAAswAAALQAAAC1AAAAtgAA ALcAAAD+////uQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAA /v///8YAAADHAAAAyAAAAMkAAADKAAAAywAAAMwAAAD+////zgAAAM8AAADQAAAA0QAAANIAAADT AAAA1AAAAP7////9/////f///9gAAAD+/////v////7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAA AAAAAAAA8DRpXR9EyAHaAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuAAAAAMZAAAAAAAAVwBv AHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAtV4BAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAMUAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzQAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNl IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AAAwhbHeH0TIAdoAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4AAAAAxkAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC1 XgEAAAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0A AACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAA AJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAA qgAAAKsAAACsAAAArQAAAK4AAACvAAAA/v///7EAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAD+ ////uQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAA/v///8YA AADHAAAAyAAAAMkAAADKAAAAywAAAMwAAAD+//////////////////////////////////////// ///////9/////////////////////v////7////lAAAA/f///94AAADfAAAA4AAAAOEAAADiAAAA 4wAAAOQAAAD+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN 1ZwuGxCTlwgAKyz5rnQBAAAwAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAlAAAAAYAAACcAAAA EQAAAKQAAAAXAAAArAAAAAsAAAC0AAAAEAAAALwAAAATAAAAxAAAABYAAADMAAAADQAAANQAAAAM AAAADwEAAAIAAADkBAAAHgAAABwAAABUaGUgQm9laW5nIENvbXBhbnksIE0mQ1QAAAAAAwAAACUA AAADAAAACgAAAAMAAAC8FAAAAwAAAMQfCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AB4QAAABAAAALwAAAEJvZWluZyBWb1dMQU4gSW1wbGVtZW50YXRpb24gYW5kIERlbW9uc3RyYXRp b24ADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAYAEAAAMAAAAAAAAAIAAAAAEAAAA4 AAAAAgAAAEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAAAYAQAADAAAAAMA AAA+ADIAAwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAADQAAABoAHQAdABwADoALwAvAHcAdwB3 AC4AbwBwAGUAbgBnAHIAbwB1AHAALgBvAHIAZwAvAGIAbwBvAGsAcwB0AG8AcgBlAC8AYwBhAHQA YQBsAG8AZwAvAGUAMAA0ADEALgBoAHQAbQAAAB8AAAABAAAAAAB+EAMAAAByAFgAAwAAAAAAAAAD AAAAAAAAAAMAAAAFAAAAHwAAACIAAABtAGEAaQBsAHQAbwA6AHMAdABlAHYAZQBuAC4AYwAuAHYA ZQBuAGUAbQBhAEAAYgBvAGUAaQBuAGcALgBjAG8AbQAAAB8AAAABAAAAAAB+EAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA xQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADdAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_001_01C8441F.F313CEC2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_001_01C8441F.F313CEC2-- From p2psip-bounces@ietf.org Fri Dec 21 17:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qg7-0005lt-PG; Fri, 21 Dec 2007 17:49:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qg5-0005lP-HQ; Fri, 21 Dec 2007 17:49:13 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5qg5-0000K7-4f; Fri, 21 Dec 2007 17:49:13 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBLMnBUF023223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Dec 2007 16:49:12 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBLMnBPk024121; Fri, 21 Dec 2007 14:49:11 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBLMnAAV024113; Fri, 21 Dec 2007 14:49:11 -0800 (PST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 14:49:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Date: Fri, 21 Dec 2007 14:49:07 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D070BA68A@XCH-NW-2V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIP Implementation Thread-Index: AchEI50GVcywQHvhTAWBKzgatEfhSQ== From: "Paine, Richard H" To: "Venema, Steve A" , "Mattes, David" , "Brewer, Orlie T" , , X-OriginalArrivalTime: 21 Dec 2007 22:49:10.0621 (UTC) FILETIME=[B38178D0:01C84423] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Subject: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIP HIP Implementation X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0603182601==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0603182601== Content-class: urn:content-classes:calendarmessage Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84423.B3692020" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84423.B3692020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Monday, December 17, 2007 8:00 AM-8:30 AM (GMT-08:00) Pacific Time = (US & Canada). Where: Virtual (866-752-6974 Passcode: 9710856# *~*~*~*~*~*~*~*~*~* The teleconference is per a meeting at the Vancouver IETF on Friday, Dec = 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. = The joint meeting determined the need to look at the Boeing = demonstration of SIP over HIP. The demonstration used an = IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP = call traversed both the wireless and wired network securely to get to a = wired laptop. The call occurred in a HIP namespace using a = cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the = demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 pm, Pacific Standard = Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting = number: 896 132 416 Meeting password: hipmeeting Teleconference: = Dial-in:1-866-752-6974 (US) Leader passcode:9710856 Participant passcode:9710856 Host: Richard Paine Host's email address: = richard.h.paine@boeing.com=20 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 ------_=_NextPart_001_01C84423.B3692020 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-08.00) Pacific Time (US & Canada)/Tijuana X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20071221T224832Z DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20071217T0800 00 SUMMARY:P2PSIP and HIP Joint Meeting on the Boeing VOIP HIP Implementation UID:040000008200E00074C5B7101A82E00800000000B06ED28EE043C801000000000000000 010000000009C6350D71D43428DE4DFBF56DB8769 ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Venema, S teve A":MAILTO:Steve.A.Venema@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mattes, D avid":MAILTO:david.mattes@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Brewer, O rlie T":MAILTO:brewer@redwood.rt.cs.boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'p2psip@i etf.org'":MAILTO:p2psip@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'hipsec@i etf.org'":MAILTO:hipsec@ietf.org ORGANIZER;CN="Paine, Richard H":MAILTO:richard.h.paine@boeing.com LOCATION:Virtual (866-752-6974 Passcode: 9710856# DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20071217T083000 DESCRIPTION:The teleconference is per a meeting at the Vancouver IETF on Fr iday\, Dec 7\, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demo nstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wirel ess connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call oc curred in a HIP namespace using a cryptographic identity as an SPI value i n the ESP field.\N\NThis teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point S IP.\N\NTeleconference Details:\N\NDate: Tuesday\, January 8\, 2008 Startin g time: 8:00 pm\, Pacific Standard Time (GMT -08:00\, San Francisco) Durat ion: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hipme eting Teleconference: Dial-in:1-866-752-6974 (US)\NLeader passcode:9710856 \NParticipant passcode:9710856 Host: Richard Paine Host's email address: r ichard.h.paine@boeing.com \N\NRichard H. Paine\NSuccess is getting what yo u want\, happiness is liking what you get!\NCell: 206-854-8199\NIPPhone: 425-373-8296\NEmail: richard.h.paine@boeing.com \N\N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20071221T224909Z LAST-MODIFIED:20071221T224910Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:1461045207 X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20071221T224832Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20071221T224832Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C84423.B3692020-- --===============0603182601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0603182601==-- From p2psip-bounces@ietf.org Fri Dec 21 17:56:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qlT-0003ES-Hq; Fri, 21 Dec 2007 17:54:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qlS-0003Dx-6F; Fri, 21 Dec 2007 17:54:46 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5qlJ-0004bM-9V; Fri, 21 Dec 2007 17:54:46 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBLMsawi009075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Dec 2007 14:54:36 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBLMsaZD004139; Fri, 21 Dec 2007 14:54:36 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBLMsa6W004133; Fri, 21 Dec 2007 14:54:36 -0800 (PST) Received: from XCH-NW-2V2.nw.nos.boeing.com ([130.247.55.18]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 14:54:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:calendarmessage MIME-Version: 1.0 Date: Fri, 21 Dec 2007 14:54:33 -0800 Message-ID: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation Thread-Index: AchEJF77+AuPbUl7TLicLKCnqCbpYw== From: "Paine, Richard H" To: "Venema, Steve A" , "Mattes, David" , "Brewer, Orlie T" , , X-OriginalArrivalTime: 21 Dec 2007 22:54:35.0887 (UTC) FILETIME=[75611FF0:01C84424] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Subject: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0815744511==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0815744511== Content-class: urn:content-classes:calendarmessage Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84424.7530E116" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84424.7530E116 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time = (US & Canada). Where: Virtual (866-752-6974 Passcode: 9710856# *~*~*~*~*~*~*~*~*~* The teleconference is per a meeting at the Vancouver IETF on Friday, Dec = 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. = The joint meeting determined the need to look at the Boeing = demonstration of SIP over HIP. The demonstration used an = IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP = call traversed both the wireless and wired network securely to get to a = wired laptop. The call occurred in a HIP namespace using a = cryptographic identity as an SPI value in the ESP field. This teleconference is being held to discuss the white paper on the = demonstration and the use of HIP for secure point-to-point SIP. Teleconference Details: Date: Tuesday, January 8, 2008 Starting time: 8:00 pm, Pacific Standard = Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting = number: 896 132 416 Meeting password: hipmeeting Teleconference: = Dial-in:1-866-752-6974 (US) Leader passcode:9710856 Participant passcode:9710856 Host: Richard Paine Host's email address: = richard.h.paine@boeing.com=20 Richard H. Paine Success is getting what you want, happiness is liking what you get! Cell: 206-854-8199 IPPhone: 425-373-8296 Email: richard.h.paine@boeing.com=20 ------_=_NextPart_001_01C84424.7530E116 Content-class: urn:content-classes:calendarmessage Content-Type: text/calendar; method=REQUEST; name="meeting.ics" Content-Transfer-Encoding: 8bit BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:(GMT-08.00) Pacific Time (US & Canada)/Tijuana X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20071221T225357Z DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20080108T0800 00 SUMMARY:P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation UID:040000008200E00074C5B7101A82E0080000000080ACA250E143C801000000000000000 01000000020FE7606F6D5FC42BF9DE36E7AF87CFA ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Venema, S teve A":MAILTO:Steve.A.Venema@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mattes, D avid":MAILTO:david.mattes@boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Brewer, Orlie T'":MAILTO:brewer@thumper.rt.cs.boeing.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'p2psip@i etf.org'":MAILTO:p2psip@ietf.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'hipsec@i etf.org'":MAILTO:hipsec@ietf.org ORGANIZER;CN="Paine, Richard H":MAILTO:richard.h.paine@boeing.com LOCATION:Virtual (866-752-6974 Passcode: 9710856# DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20080108T093000 DESCRIPTION:The teleconference is per a meeting at the Vancouver IETF on Fr iday\, Dec 7\, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demo nstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wirel ess connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call oc curred in a HIP namespace using a cryptographic identity as an SPI value i n the ESP field.\N\NThis teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point S IP.\N\NTeleconference Details:\N\NDate: Tuesday\, January 8\, 2008 Startin g time: 8:00 pm\, Pacific Standard Time (GMT -08:00\, San Francisco) Durat ion: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hipme eting Teleconference: Dial-in:1-866-752-6974 (US)\NLeader passcode:9710856 \NParticipant passcode:9710856 Host: Richard Paine Host's email address: r ichard.h.paine@boeing.com \N\NRichard H. Paine\NSuccess is getting what yo u want\, happiness is liking what you get!\NCell: 206-854-8199\NIPPhone: 425-373-8296\NEmail: richard.h.paine@boeing.com \N SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20071221T225435Z LAST-MODIFIED:20071221T225435Z STATUS:CONFIRMED TRANSP:OPAQUE X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-OWNERAPPTID:1471530967 X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-ATTENDEE-CRITICAL-CHANGE:20071221T225357Z X-MICROSOFT-CDO-OWNER-CRITICAL-CHANGE:20071221T225357Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT00H15M00S END:VALARM END:VEVENT END:VCALENDAR ------_=_NextPart_001_01C84424.7530E116-- --===============0815744511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0815744511==-- From p2psip-bounces@ietf.org Sat Dec 22 11:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67G2-0005QM-6u; Sat, 22 Dec 2007 11:31:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67G0-0005QA-Pn for p2psip@ietf.org; Sat, 22 Dec 2007 11:31:24 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J67G0-0001yG-5t for p2psip@ietf.org; Sat, 22 Dec 2007 11:31:24 -0500 Received: by py-out-1112.google.com with SMTP id d32so3351749pye.12 for ; Sat, 22 Dec 2007 08:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=FP1L9kwoSsWZ1r/97wrMJI8kXGynOaJALlZuEkZRf3E=; b=KEPUgRnntnFe5Ub6VB/RbaHZ9jHpyVkALuxGcfAf9EMVzVBOxI+qYDnpD3c0cWmaFNTL5WWwIV+5usZ6iqA5dwIJ4uTpppQTkzOHhekgEAa2WnGd4NH7rz8zr79Cs3WVKav4dVZzNs6IcYQeQ+Ie6CIqhdS1cti1a9w9zSBrDvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=flTs7jmSeFQCs59OTALhgC+Oek4wTArXg9wMEYZqeFN5WTwZS+MGLimS1CSWKH8kmKKeYVscX2NyxmIsTW2iwjdBd5eYf6kAkp/iravhpTK0fkVthIoyTrLIXjf4iZsdGWaEWpuWROvreTZPfD3pmfSkiUlczL2k8Ur/2we8B4U= Received: by 10.65.59.11 with SMTP id m11mr3592687qbk.96.1198341082514; Sat, 22 Dec 2007 08:31:22 -0800 (PST) Received: by 10.65.180.16 with HTTP; Sat, 22 Dec 2007 08:31:22 -0800 (PST) Message-ID: <4d4304a00712220831m7ac65f95j9ea045bd0a1e7136@mail.gmail.com> Date: Sat, 22 Dec 2007 11:31:22 -0500 From: "David A. Bryan" To: "Paine, Richard H" Subject: Re: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation In-Reply-To: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> X-Google-Sender-Auth: e13aa50dcfe7e565 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: hipsec@ietf.org, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just a clarification here for process purposes -- the meeting in the hall was NOT a joint meeting of the WGs -- just an informal in the-hall meeting of (a small number of) interested folks from both P2PSIP and HIP WGs working to ensure folks in P2PSIP better understand the HIP proposals so they were more informed about HIP and could make a better decision about HIPs applicability (or non-applicability) to P2PSIP. This meeting is a part of that process for the HIP folks -- in an organized way and encouraged by the chairs -- to make the pitch, so the P2PSIP WG can decide what they want to do/not do with respect to HIP going forward. Just wanted it to be very clear that neither the in hall group nor this call are official WG meetings in any way -- just groups of interested folks. (I'd hate to see all 200+ P2PSIP folks packed into a hallway...) David (as chair) On Dec 21, 2007 5:54 PM, Paine, Richard H wrote: > When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time (US & Canada). > > Where: Virtual (866-752-6974 Passcode: 9710856# > > *~*~*~*~*~*~*~*~*~* > > The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. > > This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. > > Teleconference Details: > > Date: Tuesday, January 8, 2008 Starting time: 8:00 pm, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hipmeeting Teleconference: Dial-in:1-866-752-6974 (US) > Leader passcode:9710856 > Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com > > Richard H. Paine > Success is getting what you want, happiness is liking what you get! > Cell: 206-854-8199 > IPPhone: 425-373-8296 > Email: richard.h.paine@boeing.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Dec 22 11:32:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67Gz-0006cJ-9I; Sat, 22 Dec 2007 11:32:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67Gy-0006c9-A6 for p2psip@ietf.org; Sat, 22 Dec 2007 11:32:24 -0500 Received: from py-out-1112.google.com ([64.233.166.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J67Gx-0004Zh-Qg for p2psip@ietf.org; Sat, 22 Dec 2007 11:32:24 -0500 Received: by py-out-1112.google.com with SMTP id d32so3353029pye.12 for ; Sat, 22 Dec 2007 08:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ck3HNiGYjC0o+VVkZP2e7F+1lZ6Ohg1tdadkuRjZTfQ=; b=JgJ7LyFurEma/RLs069BDkMWnpS/6BitiKYByMRiQs0VV2Mg6+JdW7BACarnFwUbhfHV4QUfQLeAxdxJW5lEgPIUJDH5KAmwlDayeZRfPdxM6+NGEcnpGPTu8mvF/uQ+P0bzbvs2AhcsA6t3KWsDqf2tvaLOk1ziXe5OeWVAeD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=s9Lfimooi9V6a2eGkqt++veA3FUqoMiYIB+LuGSH7wnB9xflSOA0MoQFHZDxsGhEd9QMfWqenOZhsyJ9H3VG/WMrazFAvvaeKATkMsA6e6eX7iC9E7lPt70pp3oYT3tuSAF2kF9nDCl6BHL6hyMiCGgxBZj0wrau1wX7DB3XSmw= Received: by 10.65.239.14 with SMTP id q14mr3557363qbr.77.1198341142520; Sat, 22 Dec 2007 08:32:22 -0800 (PST) Received: by 10.65.180.16 with HTTP; Sat, 22 Dec 2007 08:32:22 -0800 (PST) Message-ID: <4d4304a00712220832g4b8b7cedh9fdeb3572a1d0c9f@mail.gmail.com> Date: Sat, 22 Dec 2007 11:32:22 -0500 From: "David A. Bryan" To: "Paine, Richard H" Subject: Re: [P2PSIP] P2PSIP and HIP Joint Meeting on the Boeing VOIP HIPImplementation In-Reply-To: <4d4304a00712220831m7ac65f95j9ea045bd0a1e7136@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0C549DAFE1A8004D8EB57ACDD108646D070BA68B@XCH-NW-2V2.nw.nos.boeing.com> <4d4304a00712220831m7ac65f95j9ea045bd0a1e7136@mail.gmail.com> X-Google-Sender-Auth: 721d57022a9ac413 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: hipsec@ietf.org, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org ...and now as an individual...thanks for organizing this and I look forward to the call! David On Dec 22, 2007 11:31 AM, David A. Bryan wrote: > Just a clarification here for process purposes -- the meeting in the > hall was NOT a joint meeting of the WGs -- just an informal in > the-hall meeting of (a small number of) interested folks from both > P2PSIP and HIP WGs working to ensure folks in P2PSIP better understand > the HIP proposals so they were more informed about HIP and could make > a better decision about HIPs applicability (or non-applicability) to > P2PSIP. This meeting is a part of that process for the HIP folks -- in > an organized way and encouraged by the chairs -- to make the pitch, so > the P2PSIP WG can decide what they want to do/not do with respect to > HIP going forward. > > Just wanted it to be very clear that neither the in hall group nor > this call are official WG meetings in any way -- just groups of > interested folks. (I'd hate to see all 200+ P2PSIP folks packed into a > hallway...) > > David (as chair) > > > On Dec 21, 2007 5:54 PM, Paine, Richard H wrote: > > When: Tuesday, January 08, 2008 8:00 AM-9:30 AM (GMT-08:00) Pacific Time (US & Canada). > > > > Where: Virtual (866-752-6974 Passcode: 9710856# > > > > *~*~*~*~*~*~*~*~*~* > > > > The teleconference is per a meeting at the Vancouver IETF on Friday, Dec 7, 2007 that was a joint meeting of the HIP and P2PSIP Working Groups. The joint meeting determined the need to look at the Boeing demonstration of SIP over HIP. The demonstration used an IEEE802.11-WPA-wireless connection to the Boeing Intranet and the SIP call traversed both the wireless and wired network securely to get to a wired laptop. The call occurred in a HIP namespace using a cryptographic identity as an SPI value in the ESP field. > > > > This teleconference is being held to discuss the white paper on the demonstration and the use of HIP for secure point-to-point SIP. > > > > Teleconference Details: > > > > Date: Tuesday, January 8, 2008 Starting time: 8:00 pm, Pacific Standard Time (GMT -08:00, San Francisco) Duration: 1 hour 30 minutes Meeting number: 896 132 416 Meeting password: hipmeeting Teleconference: Dial-in:1-866-752-6974 (US) > > Leader passcode:9710856 > > Participant passcode:9710856 Host: Richard Paine Host's email address: richard.h.paine@boeing.com > > > > Richard H. Paine > > Success is getting what you want, happiness is liking what you get! > > Cell: 206-854-8199 > > IPPhone: 425-373-8296 > > Email: richard.h.paine@boeing.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 04:34:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6NDd-0003hw-Ol; Sun, 23 Dec 2007 04:34:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6NDc-0003hr-H9 for p2psip@ietf.org; Sun, 23 Dec 2007 04:34:00 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6NDb-0007BB-HR for p2psip@ietf.org; Sun, 23 Dec 2007 04:34:00 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5A4412066D; Sun, 23 Dec 2007 10:33:58 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-f5-476e2b86095c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B90E203FB; Sun, 23 Dec 2007 10:33:58 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Dec 2007 10:33:57 +0100 Received: from [159.107.2.12] ([159.107.2.12]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Dec 2007 10:33:56 +0100 Message-ID: <476E2B7C.9070601@ericsson.com> Date: Sun, 23 Dec 2007 11:33:48 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] New draft: HIP BONE References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> In-Reply-To: <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2007 09:33:57.0049 (UTC) FILETIME=[F0D3AA90:01C84546] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Bruce, thanks for your comments. Regarding your question about Sections 3.2 and 3.3 when RELOAD is the peer protocol and HIP BONE is used for connection management, the idea is to use HIP, instead of RELOAD, to perform connection management. All the other functions RELOAD typically performs are still performed by RELOAD. RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is being used, you would use the CONNECT primitive of HIP (i.e., an I1 packet) *instead* of the CONNECT primitive of RELOAD. The same way, you would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of the TUNNEL primitive of RELOAD. Regarding when to use these primitives, you would use them in the same way as defined by RELOAD. That is, when RELOADs tells you to use a CONNECT primitive today, you would send an I1 message. When RELOAD tells you to use the TUNNEL primitive today, you would use a HIP message as well. That is, RELOAD (not HIP BONE) tells you what to do (i.e., which primitive to use) and when to do it. As you can see, the only modifications to RELOAD in this context is the substitution of these two primitives by the HIP equivalent ones. Cheers, Gonzalo Bruce Lowekamp wrote: > Gonzalo, > > Many thanks to you, Pekka, and Jani for putting in yet more effort to > try to clarify a possible role for HIP in P2PSIP. > > At a high level, in section 5 you list two potential outcomes, which > are for the wg to settle on HIP for all connection management or for > the wg to not use hip, but retain modularity that allows it. I would > rather see option 2 reworded along the lines of "the wg will develop a > protocol that uses HIP as one possible choice for its connection > management layer. The HIP module will not be mandatory to implement, > but its specification will be developed by the wg." I think that's > something along the lines of what you're thinking. It's certainly > what I'm hoping the outcome will be. I am sure there are other > options as well (ignore hip, try to maintain compatibility but don't > specify, etc). > > > On a specific issue, I'm still a little confused about where the line > is between what the overlay does with overlay routing and what > HIP-BONE should be responsible for. Your section 3.2 proposes that I1 > packets are sent across the Peer Protocol overlay. Were I to > implement RELOAD on top of HIP-BONE, what exactly does this mean? > Does this mean that I send a RELOAD CONNECT message and the contents > of that message are now an I1 instead of ICE candidates? Or would > RELOAD's CONNECT go away and RELOAD would simply try to send a message > directly to a new PeerID via its ORCHID and the HIP-BONE layer would > then produce an upcall to RELOAD asking that an I1 be tunneled across > the overlay? > > Similarly, in section 3.3, you suggest that a HIP message could be > tunneled through the overlay rather than establishing a new connection > for a simple query. Generally, dht maintenance operations and > resource query operations are somewhat distinct. If I'm using > recursive routing, a resource query operation would never cause a new > connection to be formed, but instead the query would be routed across > the overlay by the Peer Protocol. Assuming I'm understanding your > layering correctly, that would be implemented by the Peer Protocol > knowing the translation between the PeerID of the next hop that it has > a connection to and that peer's ORCHID (or LSI) and the Peer Protocol > would route the query message to that next hop just like it has a > direct IP connection (and generally be unaware of the difference). > So I'm unclear on when the mechanism in 3.3 would be invoked. If I'm > using recursive routing, the only time I would send a message to a new > peer for which I do not have an existing connection would be: > - during dht maintenance if I decide I should have a connection with > this new peer > - if the application decides it wants to send an application-layer > message directly > RELOAD proposes to solve the first case using CONNECT messages, as > discussed above. It also proposes to solve the second case with a > CONNECT message (or TUNNEL, as decided by the application). This is I > think where HIP (or at least id/loc) has its biggest potential win. > Is the use of a new ORCHID by the application the proposed application > of section 3.3? If so, how would the decision be made of when to > tunnel and when to open a new direct connection? > > Bruce > > > > > On Dec 21, 2007 6:51 AM, Gonzalo Camarillo > wrote: >> Hi, >> >> we have seen a lot of discussions on how HIP could relate to P2PSIP on >> this list lately. While this level of interest on HIP is a good thing >> (from the HIP community's perspective), there have been a few >> misconceptions and misunderstandings on what is essential to HIP (e.g., >> the ID/locator split) and what are just design or configuration choices >> made in a given HIP deployment (e.g., using self-certifying identifiers). >> >> With the draft below, we have tried to clarify a few of the design >> choices that can be made while defining the use of HIP in a given >> scenario (e.g., the use of a centralized enrollment server). In >> particular, we have focused on the use of HIP to build overlays. The >> draft also includes tutorial material on HIP so that readers who are not >> familiar with HIP can still follow what it is said in the draft. >> >> http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt >> >> The draft also discusses the relationship between HIP and P2PSIP. It >> clarifies that while HIP can be used to implement connection management, >> other functions such as overlay maintenance, and data storage and >> retrieval are implemented using a peer protocol such as RELOAD or P2PP. >> We thought that this clarification was important because it seems some >> people mistakingly thought HIP was a full-blown peer protocol proposal >> while, in reality, HIP only provides connection management. >> >> Enjoy your Christmas reading! ;o) >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 04:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6NPi-0004zR-Mv; Sun, 23 Dec 2007 04:46:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6NPh-0004id-C4 for p2psip@ietf.org; Sun, 23 Dec 2007 04:46:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6NPg-0007LS-RG for p2psip@ietf.org; Sun, 23 Dec 2007 04:46:29 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C95F020276; Sun, 23 Dec 2007 10:46:27 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-bb-476e2e735cf6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A582220133; Sun, 23 Dec 2007 10:46:27 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Dec 2007 10:46:27 +0100 Received: from [159.107.2.12] ([159.107.2.12]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Dec 2007 10:46:26 +0100 Message-ID: <476E2E6C.4030407@ericsson.com> Date: Sun, 23 Dec 2007 11:46:20 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Salman Abdul Baset Subject: Re: [P2PSIP] New draft: HIP BONE References: <476BA8D9.4010203@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2007 09:46:27.0207 (UTC) FILETIME=[AFF4B170:01C84548] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Salman, thanks for your comments. > My general concern with running a peer protocol (RELOAD or P2PP) on top > of HIP is that one will need to understand somewhat two completely > different documents (HIP and peer protocol document) to implement a > working solution. That increases the bar for someone who will like to > quickly design and develop a working p2p solution. that is because you get things like mobility and multihoming. If you want to implement these features without using HIP you will need to anyway read more specifications (e.g., mobile IP and SHIM-6). > I think there is a need to carefully perform message overhead analysis > of HIP under different levels of churn. The only difference is that, every time you a node establishes a connection with another node, there will be a HIP four-way handshake instead of a TLS or DTLS handshake. > I am a bit confused about > splitting the functionality between the overlay layer and the HIP layer. > Is peer protocol no more than an encoding mechanism when implemented on > top of HIP? No, the peer protocol provides all the functions it provides today except for the CONNECT and TUNNEL primitives (and NAT traversal). If you mean that the peer protocol runs inside secure connections managed by HIP, that is also the case today: the peer protocol runs inside secure connections managed by TLS. Cheers, Gonzalo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 16:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6XwX-0002Ig-RY; Sun, 23 Dec 2007 16:01:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6XwW-0002IX-8o for p2psip@ietf.org; Sun, 23 Dec 2007 16:01:04 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6XwU-0003Yr-0H for p2psip@ietf.org; Sun, 23 Dec 2007 16:01:04 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0C5452F1B; Sun, 23 Dec 2007 23:01:01 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7A0E12EDE; Sun, 23 Dec 2007 23:00:52 +0200 (EET) Date: Sun, 23 Dec 2007 23:00:52 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: <20071218084807.4047C33C69@delta.rtfm.com> Message-ID: References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Tue, 18 Dec 2007, Eric Rescorla wrote: > At Mon, 17 Dec 2007 17:30:24 -0500, > Philip Matthews wrote: >> In all three proposals, media packets would flow directly between the >> X and Y, and not hop-by-hop around the overlay. So when ESP was used, >> there would be no need to use STRP for media, or TLS or DTLS for >> signaling. > > This is arguably a bug, not a feature. > > SRTP was explicitly designed to have very low overhead: just the > bits of the authentication tag itself, with no header, etc. The > rationale for this design was that RTP packets tend to be very > small and so the overhead for the header, IV, etc. was significant. > In cases where that type of constraint applies, then wrapping the > RTP in ESP would be bad. I think the difference is around 18 bytes: http://dasan.sejong.ac.kr/~wisa04/ppt/1A1.ppt In practice, the difference is insignificant according to these results: Bilien et at: Secure VoIP: call establishment and media protection: http://www.minisip.org/publications/secvoip-minisip-camera.pdf Currently, all three (public) HIP implementations support BEET-mode-ESP by default. It has exactly the same byte overhead as transport mode. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 16:33:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6YSJ-00046L-A9; Sun, 23 Dec 2007 16:33:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6YSI-00046G-6t for p2psip@ietf.org; Sun, 23 Dec 2007 16:33:54 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6YSH-00049f-LY for p2psip@ietf.org; Sun, 23 Dec 2007 16:33:54 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 979885081A; Sun, 23 Dec 2007 13:33:31 -0800 (PST) Date: Sun, 23 Dec 2007 13:33:31 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071223213331.979885081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > On Tue, 18 Dec 2007, Eric Rescorla wrote: > > > At Mon, 17 Dec 2007 17:30:24 -0500, > > Philip Matthews wrote: > >> In all three proposals, media packets would flow directly between the > >> X and Y, and not hop-by-hop around the overlay. So when ESP was used, > >> there would be no need to use STRP for media, or TLS or DTLS for > >> signaling. > > > > This is arguably a bug, not a feature. > > > > SRTP was explicitly designed to have very low overhead: just the > > bits of the authentication tag itself, with no header, etc. The > > rationale for this design was that RTP packets tend to be very > > small and so the overhead for the header, IV, etc. was significant. > > In cases where that type of constraint applies, then wrapping the > > RTP in ESP would be bad. > > I think the difference is around 18 bytes: > > http://dasan.sejong.ac.kr/~wisa04/ppt/1A1.ppt > > In practice, the difference is insignificant according to these results: > > Bilien et at: Secure VoIP: call establishment and media protection: > http://www.minisip.org/publications/secvoip-minisip-camera.pdf I don't see that this paper is at all relevant to the question of whether 18 bytes of per-packet overhead is significant. In any case, if you want to argue this point, I would advise you to take it up in AVT, since low overhead was one of the principal design considerations for SRTP. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 17:02:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Yu3-0001B2-TU; Sun, 23 Dec 2007 17:02:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Yu2-00016w-Bp for p2psip@ietf.org; Sun, 23 Dec 2007 17:02:34 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6Yu1-0005Xj-T6 for p2psip@ietf.org; Sun, 23 Dec 2007 17:02:34 -0500 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 2CEDB2EC6; Mon, 24 Dec 2007 00:02:28 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.2.3-niksula20070810 (2007-08-08) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.3-niksula20070810 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 52E6E2C1B; Mon, 24 Dec 2007 00:02:22 +0200 (EET) Date: Mon, 24 Dec 2007 00:02:22 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Eric Rescorla Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: <20071223213331.979885081A@romeo.rtfm.com> Message-ID: References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> <20071223213331.979885081A@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Sun, 23 Dec 2007, Eric Rescorla wrote: >> On Tue, 18 Dec 2007, Eric Rescorla wrote: >> >>> At Mon, 17 Dec 2007 17:30:24 -0500, >>> Philip Matthews wrote: >>>> In all three proposals, media packets would flow directly between the >>>> X and Y, and not hop-by-hop around the overlay. So when ESP was used, >>>> there would be no need to use STRP for media, or TLS or DTLS for >>>> signaling. >>> >>> This is arguably a bug, not a feature. >>> >>> SRTP was explicitly designed to have very low overhead: just the >>> bits of the authentication tag itself, with no header, etc. The >>> rationale for this design was that RTP packets tend to be very >>> small and so the overhead for the header, IV, etc. was significant. >>> In cases where that type of constraint applies, then wrapping the >>> RTP in ESP would be bad. >> >> I think the difference is around 18 bytes: >> >> http://dasan.sejong.ac.kr/~wisa04/ppt/1A1.ppt >> >> In practice, the difference is insignificant according to these results: >> >> Bilien et at: Secure VoIP: call establishment and media protection: >> http://www.minisip.org/publications/secvoip-minisip-camera.pdf > > I don't see that this paper is at all relevant to the question of whether 18 > bytes of per-packet overhead is significant. In any case, if you want > to argue this point, I would advise you to take it up in AVT, since > low overhead was one of the principal design considerations for > SRTP. I find this answer unsatisfying for three reasons. First, I don't think that the SRTP has been fixed for this working group unless I have mistaken. Secondly, I find the paper highly relevant to the original discussion. Thirdly, SRTP RFC does not discuss the differences between IPsec and SRTP, but merely mentions it in one sentence. Looking forward for more accurate references to SRTP, preferably with some performance results. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 17:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Z9S-0003go-NJ; Sun, 23 Dec 2007 17:18:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Z9R-0003bE-30 for p2psip@ietf.org; Sun, 23 Dec 2007 17:18:29 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6Z9Q-0005qQ-KA for p2psip@ietf.org; Sun, 23 Dec 2007 17:18:29 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 78A7A5081A; Sun, 23 Dec 2007 14:18:06 -0800 (PST) Date: Sun, 23 Dec 2007 14:18:06 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> <20071223213331.979885081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071223221806.78A7A5081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 24 Dec 2007 00:02:22 +0200 (EET), Miika Komu wrote: > > On Sun, 23 Dec 2007, Eric Rescorla wrote: > > >> On Tue, 18 Dec 2007, Eric Rescorla wrote: > >> > >>> At Mon, 17 Dec 2007 17:30:24 -0500, > >>> Philip Matthews wrote: > >>>> In all three proposals, media packets would flow directly between the > >>>> X and Y, and not hop-by-hop around the overlay. So when ESP was used, > >>>> there would be no need to use STRP for media, or TLS or DTLS for > >>>> signaling. > >>> > >>> This is arguably a bug, not a feature. > >>> > >>> SRTP was explicitly designed to have very low overhead: just the > >>> bits of the authentication tag itself, with no header, etc. The > >>> rationale for this design was that RTP packets tend to be very > >>> small and so the overhead for the header, IV, etc. was significant. > >>> In cases where that type of constraint applies, then wrapping the > >>> RTP in ESP would be bad. > >> > >> I think the difference is around 18 bytes: > >> > >> http://dasan.sejong.ac.kr/~wisa04/ppt/1A1.ppt > >> > >> In practice, the difference is insignificant according to these results: > >> > >> Bilien et at: Secure VoIP: call establishment and media protection: > >> http://www.minisip.org/publications/secvoip-minisip-camera.pdf > > > > I don't see that this paper is at all relevant to the question of whether 18 > > bytes of per-packet overhead is significant. In any case, if you want > > to argue this point, I would advise you to take it up in AVT, since > > low overhead was one of the principal design considerations for > > SRTP. > > I find this answer unsatisfying for three reasons. I wasn't aware it was my job to satisfy you. > First, I don't think > that the SRTP has been fixed for this working group unless I have > mistaken. Sure. Go ahead and explain to the RAI, SEC, and TSV ADs and the AVT chairs that you propose that RTP security for P2PSIP will be using a different set of security mechanisms from those used for ordinary SIP-based VoIP. Let me know what they say. > Secondly, I find the paper highly relevant to the original > discussion. Thirdly, SRTP RFC does not discuss the differences between > IPsec and SRTP, but merely mentions it in one sentence. Looking forward > for more accurate references to SRTP, preferably with some performance > results. As I recall, this was extensively discussed on the AVT mailing list during the period when RTP was being designed. As I said in my previous message, this is primarily a topic for the AVT WG. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Dec 23 17:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6ZA7-0004QP-6k; Sun, 23 Dec 2007 17:19:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6ZA6-0004QJ-1j for p2psip@ietf.org; Sun, 23 Dec 2007 17:19:10 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6ZA5-0005rM-PX for p2psip@ietf.org; Sun, 23 Dec 2007 17:19:09 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id D53A65081A; Sun, 23 Dec 2007 14:18:47 -0800 (PST) Date: Sun, 23 Dec 2007 14:18:47 -0800 From: Eric Rescorla To: Miika Komu Subject: Re: [P2PSIP] HIP vs. TLS/DTLS/SRTP (was HIP pros and cons) In-Reply-To: <20071223221806.78A7A5081A@romeo.rtfm.com> References: <476697F2.4080903@uni-tuebingen.de> <0F3808C7-7BFA-4874-8105-A7AE3F4606A5@magma.ca> <20071218084807.4047C33C69@delta.rtfm.com> <20071223213331.979885081A@romeo.rtfm.com> <20071223221806.78A7A5081A@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071223221847.D53A65081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Sun, 23 Dec 2007 14:18:06 -0800, Eric Rescorla wrote: > As I recall, this was extensively discussed on the AVT mailing list > during the period when RTP was being designed. As I said in my s/RTP/SRTP/ -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 24 20:20:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6yTA-0007LM-L0; Mon, 24 Dec 2007 20:20:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6yT9-0007Cf-HJ for p2psip@ietf.org; Mon, 24 Dec 2007 20:20:31 -0500 Received: from exprod6og103.obsmtp.com ([64.18.1.185] helo=psmtp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6yT7-0006fy-4b for p2psip@ietf.org; Mon, 24 Dec 2007 20:20:31 -0500 Received: from source ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Mon, 24 Dec 2007 17:20:21 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lBP1Hsin003639; Mon, 24 Dec 2007 17:17:55 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lBP1KAFV005905; Mon, 24 Dec 2007 17:20:11 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Dec 2007 17:20:09 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: HIP BONE Date: Mon, 24 Dec 2007 17:20:05 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE470@namail5.corp.adobe.com> In-Reply-To: <476E2B7C.9070601@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: HIP BONE Thread-Index: AchFRwf/OSwBdlUZQ+C1d7j7xLyOvwBTO7gg References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> From: "Henry Sinnreich" To: "Gonzalo Camarillo" , "Bruce Lowekamp" X-OriginalArrivalTime: 25 Dec 2007 01:20:09.0628 (UTC) FILETIME=[4A557DC0:01C84694] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I wonder if similar simple substitutions don't work for most of the other proposed P2PSIP protocols, in some common architectural approach. Henry -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Sunday, December 23, 2007 1:34 AM To: Bruce Lowekamp Cc: Pekka Nikander; P2PSIP Mailing List Subject: Re: [P2PSIP] New draft: HIP BONE Hi Bruce, thanks for your comments. Regarding your question about Sections 3.2 and 3.3 when RELOAD is the=20 peer protocol and HIP BONE is used for connection management, the idea=20 is to use HIP, instead of RELOAD, to perform connection management. All=20 the other functions RELOAD typically performs are still performed by RELOAD. RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is being used, you would use the CONNECT primitive of HIP (i.e., an I1=20 packet) *instead* of the CONNECT primitive of RELOAD. The same way, you=20 would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of the TUNNEL primitive of RELOAD. Regarding when to use these primitives, you would use them in the same=20 way as defined by RELOAD. That is, when RELOADs tells you to use a=20 CONNECT primitive today, you would send an I1 message. When RELOAD tells you to use the TUNNEL primitive today, you would use a HIP message as=20 well. That is, RELOAD (not HIP BONE) tells you what to do (i.e., which=20 primitive to use) and when to do it. As you can see, the only modifications to RELOAD in this context is the=20 substitution of these two primitives by the HIP equivalent ones. Cheers, Gonzalo Bruce Lowekamp wrote: > Gonzalo, >=20 > Many thanks to you, Pekka, and Jani for putting in yet more effort to > try to clarify a possible role for HIP in P2PSIP. >=20 > At a high level, in section 5 you list two potential outcomes, which > are for the wg to settle on HIP for all connection management or for > the wg to not use hip, but retain modularity that allows it. I would > rather see option 2 reworded along the lines of "the wg will develop a > protocol that uses HIP as one possible choice for its connection > management layer. The HIP module will not be mandatory to implement, > but its specification will be developed by the wg." I think that's > something along the lines of what you're thinking. It's certainly > what I'm hoping the outcome will be. I am sure there are other > options as well (ignore hip, try to maintain compatibility but don't > specify, etc). >=20 >=20 > On a specific issue, I'm still a little confused about where the line > is between what the overlay does with overlay routing and what > HIP-BONE should be responsible for. Your section 3.2 proposes that I1 > packets are sent across the Peer Protocol overlay. Were I to > implement RELOAD on top of HIP-BONE, what exactly does this mean? > Does this mean that I send a RELOAD CONNECT message and the contents > of that message are now an I1 instead of ICE candidates? Or would > RELOAD's CONNECT go away and RELOAD would simply try to send a message > directly to a new PeerID via its ORCHID and the HIP-BONE layer would > then produce an upcall to RELOAD asking that an I1 be tunneled across > the overlay? >=20 > Similarly, in section 3.3, you suggest that a HIP message could be > tunneled through the overlay rather than establishing a new connection > for a simple query. Generally, dht maintenance operations and > resource query operations are somewhat distinct. If I'm using > recursive routing, a resource query operation would never cause a new > connection to be formed, but instead the query would be routed across > the overlay by the Peer Protocol. Assuming I'm understanding your > layering correctly, that would be implemented by the Peer Protocol > knowing the translation between the PeerID of the next hop that it has > a connection to and that peer's ORCHID (or LSI) and the Peer Protocol > would route the query message to that next hop just like it has a > direct IP connection (and generally be unaware of the difference). > So I'm unclear on when the mechanism in 3.3 would be invoked. If I'm > using recursive routing, the only time I would send a message to a new > peer for which I do not have an existing connection would be: > - during dht maintenance if I decide I should have a connection with > this new peer > - if the application decides it wants to send an application-layer > message directly > RELOAD proposes to solve the first case using CONNECT messages, as > discussed above. It also proposes to solve the second case with a > CONNECT message (or TUNNEL, as decided by the application). This is I > think where HIP (or at least id/loc) has its biggest potential win. > Is the use of a new ORCHID by the application the proposed application > of section 3.3? If so, how would the decision be made of when to > tunnel and when to open a new direct connection? >=20 > Bruce >=20 >=20 >=20 >=20 > On Dec 21, 2007 6:51 AM, Gonzalo Camarillo > wrote: >> Hi, >> >> we have seen a lot of discussions on how HIP could relate to P2PSIP on >> this list lately. While this level of interest on HIP is a good thing >> (from the HIP community's perspective), there have been a few >> misconceptions and misunderstandings on what is essential to HIP (e.g., >> the ID/locator split) and what are just design or configuration choices >> made in a given HIP deployment (e.g., using self-certifying identifiers). >> >> With the draft below, we have tried to clarify a few of the design >> choices that can be made while defining the use of HIP in a given >> scenario (e.g., the use of a centralized enrollment server). In >> particular, we have focused on the use of HIP to build overlays. The >> draft also includes tutorial material on HIP so that readers who are not >> familiar with HIP can still follow what it is said in the draft. >> >> http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt >> >> The draft also discusses the relationship between HIP and P2PSIP. It >> clarifies that while HIP can be used to implement connection management, >> other functions such as overlay maintenance, and data storage and >> retrieval are implemented using a peer protocol such as RELOAD or P2PP. >> We thought that this clarification was important because it seems some >> people mistakingly thought HIP was a full-blown peer protocol proposal >> while, in reality, HIP only provides connection management. >> >> Enjoy your Christmas reading! ;o) >> >> Cheers, >> >> Gonzalo >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 26 07:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7VNH-000229-9v; Wed, 26 Dec 2007 07:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7VNG-0001vv-4q for p2psip@ietf.org; Wed, 26 Dec 2007 07:28:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7VND-0007M1-Iw for p2psip@ietf.org; Wed, 26 Dec 2007 07:28:38 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8572C20A46; Wed, 26 Dec 2007 13:28:34 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-bc-477248f28f10 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52259205B0; Wed, 26 Dec 2007 13:28:34 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 13:28:34 +0100 Received: from [159.107.2.70] ([159.107.2.70]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 13:28:31 +0100 Message-ID: <477248E8.5020200@ericsson.com> Date: Wed, 26 Dec 2007 14:28:24 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] New draft: HIP BONE References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE470@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE470@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2007 12:28:32.0661 (UTC) FILETIME=[D4047450:01C847BA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Henry, yes, HIP BONE can be used with any peer protocol. I used RELOAD in my email below as one example of a peer protocol to make the explanation easier to understand. Cheers, Gonzalo Henry Sinnreich wrote: > I wonder if similar simple substitutions don't work for most of the > other proposed P2PSIP protocols, in some common architectural approach. > > Henry > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Sunday, December 23, 2007 1:34 AM > To: Bruce Lowekamp > Cc: Pekka Nikander; P2PSIP Mailing List > Subject: Re: [P2PSIP] New draft: HIP BONE > > Hi Bruce, > > thanks for your comments. > > Regarding your question about Sections 3.2 and 3.3 when RELOAD is the > peer protocol and HIP BONE is used for connection management, the idea > is to use HIP, instead of RELOAD, to perform connection management. All > the other functions RELOAD typically performs are still performed by > RELOAD. > > RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is > > being used, you would use the CONNECT primitive of HIP (i.e., an I1 > packet) *instead* of the CONNECT primitive of RELOAD. The same way, you > would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of > > the TUNNEL primitive of RELOAD. > > Regarding when to use these primitives, you would use them in the same > way as defined by RELOAD. That is, when RELOADs tells you to use a > CONNECT primitive today, you would send an I1 message. When RELOAD tells > > you to use the TUNNEL primitive today, you would use a HIP message as > well. That is, RELOAD (not HIP BONE) tells you what to do (i.e., which > primitive to use) and when to do it. > > As you can see, the only modifications to RELOAD in this context is the > substitution of these two primitives by the HIP equivalent ones. > > Cheers, > > Gonzalo > > > Bruce Lowekamp wrote: >> Gonzalo, >> >> Many thanks to you, Pekka, and Jani for putting in yet more effort to >> try to clarify a possible role for HIP in P2PSIP. >> >> At a high level, in section 5 you list two potential outcomes, which >> are for the wg to settle on HIP for all connection management or for >> the wg to not use hip, but retain modularity that allows it. I would >> rather see option 2 reworded along the lines of "the wg will develop a >> protocol that uses HIP as one possible choice for its connection >> management layer. The HIP module will not be mandatory to implement, >> but its specification will be developed by the wg." I think that's >> something along the lines of what you're thinking. It's certainly >> what I'm hoping the outcome will be. I am sure there are other >> options as well (ignore hip, try to maintain compatibility but don't >> specify, etc). >> >> >> On a specific issue, I'm still a little confused about where the line >> is between what the overlay does with overlay routing and what >> HIP-BONE should be responsible for. Your section 3.2 proposes that I1 >> packets are sent across the Peer Protocol overlay. Were I to >> implement RELOAD on top of HIP-BONE, what exactly does this mean? >> Does this mean that I send a RELOAD CONNECT message and the contents >> of that message are now an I1 instead of ICE candidates? Or would >> RELOAD's CONNECT go away and RELOAD would simply try to send a message >> directly to a new PeerID via its ORCHID and the HIP-BONE layer would >> then produce an upcall to RELOAD asking that an I1 be tunneled across >> the overlay? >> >> Similarly, in section 3.3, you suggest that a HIP message could be >> tunneled through the overlay rather than establishing a new connection >> for a simple query. Generally, dht maintenance operations and >> resource query operations are somewhat distinct. If I'm using >> recursive routing, a resource query operation would never cause a new >> connection to be formed, but instead the query would be routed across >> the overlay by the Peer Protocol. Assuming I'm understanding your >> layering correctly, that would be implemented by the Peer Protocol >> knowing the translation between the PeerID of the next hop that it has >> a connection to and that peer's ORCHID (or LSI) and the Peer Protocol >> would route the query message to that next hop just like it has a >> direct IP connection (and generally be unaware of the difference). >> So I'm unclear on when the mechanism in 3.3 would be invoked. If I'm >> using recursive routing, the only time I would send a message to a new >> peer for which I do not have an existing connection would be: >> - during dht maintenance if I decide I should have a connection with >> this new peer >> - if the application decides it wants to send an application-layer >> message directly >> RELOAD proposes to solve the first case using CONNECT messages, as >> discussed above. It also proposes to solve the second case with a >> CONNECT message (or TUNNEL, as decided by the application). This is I >> think where HIP (or at least id/loc) has its biggest potential win. >> Is the use of a new ORCHID by the application the proposed application >> of section 3.3? If so, how would the decision be made of when to >> tunnel and when to open a new direct connection? >> >> Bruce >> >> >> >> >> On Dec 21, 2007 6:51 AM, Gonzalo Camarillo >> wrote: >>> Hi, >>> >>> we have seen a lot of discussions on how HIP could relate to P2PSIP > on >>> this list lately. While this level of interest on HIP is a good thing >>> (from the HIP community's perspective), there have been a few >>> misconceptions and misunderstandings on what is essential to HIP > (e.g., >>> the ID/locator split) and what are just design or configuration > choices >>> made in a given HIP deployment (e.g., using self-certifying > identifiers). >>> With the draft below, we have tried to clarify a few of the design >>> choices that can be made while defining the use of HIP in a given >>> scenario (e.g., the use of a centralized enrollment server). In >>> particular, we have focused on the use of HIP to build overlays. The >>> draft also includes tutorial material on HIP so that readers who are > not >>> familiar with HIP can still follow what it is said in the draft. >>> >>> http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt >>> >>> The draft also discusses the relationship between HIP and P2PSIP. It >>> clarifies that while HIP can be used to implement connection > management, >>> other functions such as overlay maintenance, and data storage and >>> retrieval are implemented using a peer protocol such as RELOAD or > P2PP. >>> We thought that this clarification was important because it seems > some >>> people mistakingly thought HIP was a full-blown peer protocol > proposal >>> while, in reality, HIP only provides connection management. >>> >>> Enjoy your Christmas reading! ;o) >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >>> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 26 07:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7VmF-0003lm-1l; Wed, 26 Dec 2007 07:54:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7VmD-0003lf-U6 for p2psip@ietf.org; Wed, 26 Dec 2007 07:54:25 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7VmC-0002wq-To for p2psip@ietf.org; Wed, 26 Dec 2007 07:54:25 -0500 Received: from p54a0423b.dip0.t-ipconnect.de ([84.160.66.59] helo=[192.168.178.20]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J7VlV-00058M-3Q; Wed, 26 Dec 2007 13:53:41 +0100 Message-ID: <47724ED2.7060508@uni-tuebingen.de> Date: Wed, 26 Dec 2007 13:53:38 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [P2PSIP] New draft: HIP BONE References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> In-Reply-To: <476E2B7C.9070601@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Gonzalo, what is if peers add the HIP ORCHID at the first position of the list of gathered addresses for ICE? Since a HIP overlay, let's say a HIP BONE, will provide e2e connectivity, peers in the same HIP BONE will then be able to communicate as if they would be in the same private network if they use the HIP ORCHID as "IP addresses" and they woule be able to benefit from all the advantages of using HIP. If they are not in the same HIP BONE, they would need to establish connectivity through other type of addresses, e.g. those retreived by STUN. Do you think that would work? Cheers, Ali Gonzalo Camarillo wrote: > Hi Bruce, > > thanks for your comments. > > Regarding your question about Sections 3.2 and 3.3 when RELOAD is the > peer protocol and HIP BONE is used for connection management, the idea > is to use HIP, instead of RELOAD, to perform connection management. All > the other functions RELOAD typically performs are still performed by > RELOAD. > > RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is > being used, you would use the CONNECT primitive of HIP (i.e., an I1 > packet) *instead* of the CONNECT primitive of RELOAD. The same way, you > would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of > the TUNNEL primitive of RELOAD. > > Regarding when to use these primitives, you would use them in the same > way as defined by RELOAD. That is, when RELOADs tells you to use a > CONNECT primitive today, you would send an I1 message. When RELOAD tells > you to use the TUNNEL primitive today, you would use a HIP message as > well. That is, RELOAD (not HIP BONE) tells you what to do (i.e., which > primitive to use) and when to do it. > > As you can see, the only modifications to RELOAD in this context is the > substitution of these two primitives by the HIP equivalent ones. > > Cheers, > > Gonzalo > > > Bruce Lowekamp wrote: >> Gonzalo, >> >> Many thanks to you, Pekka, and Jani for putting in yet more effort to >> try to clarify a possible role for HIP in P2PSIP. >> >> At a high level, in section 5 you list two potential outcomes, which >> are for the wg to settle on HIP for all connection management or for >> the wg to not use hip, but retain modularity that allows it. I would >> rather see option 2 reworded along the lines of "the wg will develop a >> protocol that uses HIP as one possible choice for its connection >> management layer. The HIP module will not be mandatory to implement, >> but its specification will be developed by the wg." I think that's >> something along the lines of what you're thinking. It's certainly >> what I'm hoping the outcome will be. I am sure there are other >> options as well (ignore hip, try to maintain compatibility but don't >> specify, etc). >> >> >> On a specific issue, I'm still a little confused about where the line >> is between what the overlay does with overlay routing and what >> HIP-BONE should be responsible for. Your section 3.2 proposes that I1 >> packets are sent across the Peer Protocol overlay. Were I to >> implement RELOAD on top of HIP-BONE, what exactly does this mean? >> Does this mean that I send a RELOAD CONNECT message and the contents >> of that message are now an I1 instead of ICE candidates? Or would >> RELOAD's CONNECT go away and RELOAD would simply try to send a message >> directly to a new PeerID via its ORCHID and the HIP-BONE layer would >> then produce an upcall to RELOAD asking that an I1 be tunneled across >> the overlay? >> >> Similarly, in section 3.3, you suggest that a HIP message could be >> tunneled through the overlay rather than establishing a new connection >> for a simple query. Generally, dht maintenance operations and >> resource query operations are somewhat distinct. If I'm using >> recursive routing, a resource query operation would never cause a new >> connection to be formed, but instead the query would be routed across >> the overlay by the Peer Protocol. Assuming I'm understanding your >> layering correctly, that would be implemented by the Peer Protocol >> knowing the translation between the PeerID of the next hop that it has >> a connection to and that peer's ORCHID (or LSI) and the Peer Protocol >> would route the query message to that next hop just like it has a >> direct IP connection (and generally be unaware of the difference). >> So I'm unclear on when the mechanism in 3.3 would be invoked. If I'm >> using recursive routing, the only time I would send a message to a new >> peer for which I do not have an existing connection would be: >> - during dht maintenance if I decide I should have a connection with >> this new peer >> - if the application decides it wants to send an application-layer >> message directly >> RELOAD proposes to solve the first case using CONNECT messages, as >> discussed above. It also proposes to solve the second case with a >> CONNECT message (or TUNNEL, as decided by the application). This is I >> think where HIP (or at least id/loc) has its biggest potential win. >> Is the use of a new ORCHID by the application the proposed application >> of section 3.3? If so, how would the decision be made of when to >> tunnel and when to open a new direct connection? >> >> Bruce >> >> >> >> >> On Dec 21, 2007 6:51 AM, Gonzalo Camarillo >> wrote: >>> Hi, >>> >>> we have seen a lot of discussions on how HIP could relate to P2PSIP on >>> this list lately. While this level of interest on HIP is a good thing >>> (from the HIP community's perspective), there have been a few >>> misconceptions and misunderstandings on what is essential to HIP (e.g., >>> the ID/locator split) and what are just design or configuration choices >>> made in a given HIP deployment (e.g., using self-certifying >>> identifiers). >>> >>> With the draft below, we have tried to clarify a few of the design >>> choices that can be made while defining the use of HIP in a given >>> scenario (e.g., the use of a centralized enrollment server). In >>> particular, we have focused on the use of HIP to build overlays. The >>> draft also includes tutorial material on HIP so that readers who are not >>> familiar with HIP can still follow what it is said in the draft. >>> >>> http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt >>> >>> The draft also discusses the relationship between HIP and P2PSIP. It >>> clarifies that while HIP can be used to implement connection management, >>> other functions such as overlay maintenance, and data storage and >>> retrieval are implemented using a peer protocol such as RELOAD or P2PP. >>> We thought that this clarification was important because it seems some >>> people mistakingly thought HIP was a full-blown peer protocol proposal >>> while, in reality, HIP only provides connection management. >>> >>> Enjoy your Christmas reading! ;o) >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >>> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 26 08:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7W5S-0007zO-QS; Wed, 26 Dec 2007 08:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7W5R-0007rk-8i for p2psip@ietf.org; Wed, 26 Dec 2007 08:14:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7W5Q-00088W-TR for p2psip@ietf.org; Wed, 26 Dec 2007 08:14:17 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D03BB20DC9; Wed, 26 Dec 2007 14:14:09 +0100 (CET) X-AuditID: c1b4fb3c-b0f99bb0000030cf-7e-477253a1590d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A467220DC8; Wed, 26 Dec 2007 14:14:09 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 14:14:08 +0100 Received: from [159.107.2.70] ([159.107.2.70]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 14:14:06 +0100 Message-ID: <47725398.4000309@ericsson.com> Date: Wed, 26 Dec 2007 15:14:00 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ali Fessi Subject: Re: [P2PSIP] New draft: HIP BONE References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <47724ED2.7060508@uni-tuebingen.de> In-Reply-To: <47724ED2.7060508@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2007 13:14:07.0119 (UTC) FILETIME=[31E1A1F0:01C847C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Pekka Nikander , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, > what is if peers add the HIP ORCHID at the first position of the list of > gathered addresses for ICE? ORCHIDs are identifiers. You need locators (i.e., IP addresses) for the ICE process. Cheers, Gonzalo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 26 08:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7W5j-0008SD-IU; Wed, 26 Dec 2007 08:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7W5i-0008MQ-9G for p2psip@ietf.org; Wed, 26 Dec 2007 08:14:34 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7W5f-00088n-IL for p2psip@ietf.org; Wed, 26 Dec 2007 08:14:34 -0500 Received: from p54a0423b.dip0.t-ipconnect.de ([84.160.66.59] helo=[192.168.178.20]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J7W5e-00059P-DA for p2psip@ietf.org; Wed, 26 Dec 2007 14:14:30 +0100 Message-ID: <477253B4.2070505@uni-tuebingen.de> Date: Wed, 26 Dec 2007 14:14:28 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: P2PSIP Mailing List References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE470@namail5.corp.adobe.com> <477248E8.5020200@ericsson.com> In-Reply-To: <477248E8.5020200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Subject: [P2PSIP] Resolving SIP URIs with HIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, just another hint for the HIP discussion: if a HIP P2P overlay is used for P2PSIP, you will need 2 lookups in the overlay for establishing a SIP session: - one for resolving the SIP URI to a HIP Identifier (HIT/ORCHID) - and one for resolving the HIP Identifier to the current Locator (i.e. IP address) Cheers, Ali Gonzalo Camarillo wrote: > Hi Henry, > > yes, HIP BONE can be used with any peer protocol. I used RELOAD in my > email below as one example of a peer protocol to make the explanation > easier to understand. > > Cheers, > > Gonzalo > > Henry Sinnreich wrote: >> I wonder if similar simple substitutions don't work for most of the >> other proposed P2PSIP protocols, in some common architectural approach. >> >> Henry >> >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: >> Sunday, December 23, 2007 1:34 AM >> To: Bruce Lowekamp >> Cc: Pekka Nikander; P2PSIP Mailing List >> Subject: Re: [P2PSIP] New draft: HIP BONE >> >> Hi Bruce, >> >> thanks for your comments. >> >> Regarding your question about Sections 3.2 and 3.3 when RELOAD is the >> peer protocol and HIP BONE is used for connection management, the idea >> is to use HIP, instead of RELOAD, to perform connection management. >> All the other functions RELOAD typically performs are still performed by >> RELOAD. >> >> RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is >> >> being used, you would use the CONNECT primitive of HIP (i.e., an I1 >> packet) *instead* of the CONNECT primitive of RELOAD. The same way, >> you would use the TUNNEL primitive of HIP (i.e., a HIP message) >> *instead* of >> >> the TUNNEL primitive of RELOAD. >> >> Regarding when to use these primitives, you would use them in the same >> way as defined by RELOAD. That is, when RELOADs tells you to use a >> CONNECT primitive today, you would send an I1 message. When RELOAD tells >> >> you to use the TUNNEL primitive today, you would use a HIP message as >> well. That is, RELOAD (not HIP BONE) tells you what to do (i.e., >> which primitive to use) and when to do it. >> >> As you can see, the only modifications to RELOAD in this context is >> the substitution of these two primitives by the HIP equivalent ones. >> >> Cheers, >> >> Gonzalo >> >> >> Bruce Lowekamp wrote: >>> Gonzalo, >>> >>> Many thanks to you, Pekka, and Jani for putting in yet more effort to >>> try to clarify a possible role for HIP in P2PSIP. >>> >>> At a high level, in section 5 you list two potential outcomes, which >>> are for the wg to settle on HIP for all connection management or for >>> the wg to not use hip, but retain modularity that allows it. I would >>> rather see option 2 reworded along the lines of "the wg will develop a >>> protocol that uses HIP as one possible choice for its connection >>> management layer. The HIP module will not be mandatory to implement, >>> but its specification will be developed by the wg." I think that's >>> something along the lines of what you're thinking. It's certainly >>> what I'm hoping the outcome will be. I am sure there are other >>> options as well (ignore hip, try to maintain compatibility but don't >>> specify, etc). >>> >>> >>> On a specific issue, I'm still a little confused about where the line >>> is between what the overlay does with overlay routing and what >>> HIP-BONE should be responsible for. Your section 3.2 proposes that I1 >>> packets are sent across the Peer Protocol overlay. Were I to >>> implement RELOAD on top of HIP-BONE, what exactly does this mean? >>> Does this mean that I send a RELOAD CONNECT message and the contents >>> of that message are now an I1 instead of ICE candidates? Or would >>> RELOAD's CONNECT go away and RELOAD would simply try to send a message >>> directly to a new PeerID via its ORCHID and the HIP-BONE layer would >>> then produce an upcall to RELOAD asking that an I1 be tunneled across >>> the overlay? >>> >>> Similarly, in section 3.3, you suggest that a HIP message could be >>> tunneled through the overlay rather than establishing a new connection >>> for a simple query. Generally, dht maintenance operations and >>> resource query operations are somewhat distinct. If I'm using >>> recursive routing, a resource query operation would never cause a new >>> connection to be formed, but instead the query would be routed across >>> the overlay by the Peer Protocol. Assuming I'm understanding your >>> layering correctly, that would be implemented by the Peer Protocol >>> knowing the translation between the PeerID of the next hop that it has >>> a connection to and that peer's ORCHID (or LSI) and the Peer Protocol >>> would route the query message to that next hop just like it has a >>> direct IP connection (and generally be unaware of the difference). >>> So I'm unclear on when the mechanism in 3.3 would be invoked. If I'm >>> using recursive routing, the only time I would send a message to a new >>> peer for which I do not have an existing connection would be: >>> - during dht maintenance if I decide I should have a connection with >>> this new peer >>> - if the application decides it wants to send an application-layer >>> message directly >>> RELOAD proposes to solve the first case using CONNECT messages, as >>> discussed above. It also proposes to solve the second case with a >>> CONNECT message (or TUNNEL, as decided by the application). This is I >>> think where HIP (or at least id/loc) has its biggest potential win. >>> Is the use of a new ORCHID by the application the proposed application >>> of section 3.3? If so, how would the decision be made of when to >>> tunnel and when to open a new direct connection? >>> >>> Bruce >>> >>> >>> >>> >>> On Dec 21, 2007 6:51 AM, Gonzalo Camarillo >>> wrote: >>>> Hi, >>>> >>>> we have seen a lot of discussions on how HIP could relate to P2PSIP >> on >>>> this list lately. While this level of interest on HIP is a good thing >>>> (from the HIP community's perspective), there have been a few >>>> misconceptions and misunderstandings on what is essential to HIP >> (e.g., >>>> the ID/locator split) and what are just design or configuration >> choices >>>> made in a given HIP deployment (e.g., using self-certifying >> identifiers). >>>> With the draft below, we have tried to clarify a few of the design >>>> choices that can be made while defining the use of HIP in a given >>>> scenario (e.g., the use of a centralized enrollment server). In >>>> particular, we have focused on the use of HIP to build overlays. The >>>> draft also includes tutorial material on HIP so that readers who are >> not >>>> familiar with HIP can still follow what it is said in the draft. >>>> >>>> http://www.ietf.org/internet-drafts/draft-camarillo-hip-bone-00.txt >>>> >>>> The draft also discusses the relationship between HIP and P2PSIP. It >>>> clarifies that while HIP can be used to implement connection >> management, >>>> other functions such as overlay maintenance, and data storage and >>>> retrieval are implemented using a peer protocol such as RELOAD or >> P2PP. >>>> We thought that this clarification was important because it seems >> some >>>> people mistakingly thought HIP was a full-blown peer protocol >> proposal >>>> while, in reality, HIP only provides connection management. >>>> >>>> Enjoy your Christmas reading! ;o) >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>>> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 26 09:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7XVB-0000O2-NU; Wed, 26 Dec 2007 09:44:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7XVA-0000Nx-GM for p2psip@ietf.org; Wed, 26 Dec 2007 09:44:56 -0500 Received: from u-173-c156.cs.uni-tuebingen.de ([134.2.173.156] helo=smtp.cs.uni-tuebingen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7XV8-0001FO-Nl for p2psip@ietf.org; Wed, 26 Dec 2007 09:44:56 -0500 Received: from p54a0423b.dip0.t-ipconnect.de ([84.160.66.59] helo=[192.168.178.20]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1J7XV6-0005Bv-3D; Wed, 26 Dec 2007 15:44:52 +0100 Message-ID: <477268E1.4050509@uni-tuebingen.de> Date: Wed, 26 Dec 2007 15:44:49 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gonzalo Camarillo References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <47724ED2.7060508@uni-tuebingen.de> <47725398.4000309@ericsson.com> In-Reply-To: <47725398.4000309@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: P2PSIP Mailing List Subject: [P2PSIP] a modular approach for integrating HIP for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Gonzalo, all, according to draft-ietf-mmusic-ice, addresses collected for ICE can be also "obtained through a tunnel mechanism, such as a Virtual Private Network (VPN) or Mobile IP (MIP)". If i understand correctly (please correct me if i am wrong) the ORCHID (alternatively the LSI if the application uses IPv4) is bound locally to a virtual interface. So the application can use it the same way it uses an IP address obtained by a VPN (or any other IP address, e.g. obtained by STUN) So is there a reason why HIP ORCHIDs cannot be used in the ICE candidates list? Also the ICE host candidates' sorting process (as described in Section 2.3 "Sorting Candidates" in draft-ietf-mmusic-ice) could recognize the HIP ORCHID (due to the unique prefix) and give it higher priority in the host candidate list if the application should benefit from the HIP advantages. I think that could provide a simple - though modular and flexible - approach for integrating HIP for P2PSIP (at least for the NAT traversal part) In other words: - the application can easily check whether the host where it is running supports HIP. - a peer can inform another peer that it supports HIP (using the ICE candidates list and the priorities given to the addresses). If both peers support HIP and they are in the same HIP overlay, then they can (and maybe should) use it. - if one of the peer hosts does not support HIP, then the peers will need to go forward in the ICE host candidate list and use other addresses for connectivity, e.g. those obtained by STUN. I mentioned, this could provide a modular approach for the NAT traversal problem. But maybe it could be extended to cope with the other features that HIP provides, e.g. mobility and multi-homing. Any comments? Thanks in advance. Cheers, Ali Gonzalo Camarillo wrote: > Hi, > >> what is if peers add the HIP ORCHID at the first position of the list >> of gathered addresses for ICE? > > ORCHIDs are identifiers. You need locators (i.e., IP addresses) for the > ICE process. > > Cheers, > > Gonzalo > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Dec 26 16:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7eHW-0006FT-3l; Wed, 26 Dec 2007 16:59:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7eHU-00068o-Ny for p2psip@ietf.org; Wed, 26 Dec 2007 16:59:16 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7eHU-0007eK-0U for p2psip@ietf.org; Wed, 26 Dec 2007 16:59:16 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBQLx49u001884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Dec 2007 15:59:04 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBQLx41S021322; Wed, 26 Dec 2007 15:59:04 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBQLx4Ji021314; Wed, 26 Dec 2007 15:59:04 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 13:59:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: HIP BONE Date: Wed, 26 Dec 2007 13:59:03 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049ADA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: HIP BONE Thread-Index: AchEDl/oyHtQSXquRQC34GjfKWG5NAD96C1Q References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> From: "Henderson, Thomas R" To: "Pekka Nikander" , "Bruce Lowekamp" X-OriginalArrivalTime: 26 Dec 2007 21:59:03.0664 (UTC) FILETIME=[8748FF00:01C8480A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, December 21, 2007 12:16 PM > To: Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] New draft: HIP BONE >=20 > Hi Bruce, >=20 > Let me try to clarify a few of your HIP-specific questions. In =20 > general, we tried to clarify the proposed relationship between HIP =20 > and the peer protocols by the architectural analogy (in Section 6), =20 > where we state that HIP acts in a role similar to IP=20 > (forwarding that =20 > results in connectivity) and the peer protocols in a role similar to =20 > routing protocols such as OSPF, i.e., building the routing tables =20 > needed to do forwarding. >=20 > > On a specific issue, I'm still a little confused about=20 > where the line > > is between what the overlay does with overlay routing and what > > HIP-BONE should be responsible for. Your section 3.2=20 > proposes that I1 > > packets are sent across the Peer Protocol overlay. >=20 > Well, not quite. We propose that "Nodes in the overlay forward I1 =20 > packets in a hop-by-hop fashion according to the overlay's routing =20 > table towards its destination." While that is true, it is=20 > inaccurate =20 > in the sense that it does not make the distinction between the =20 > routing tables (as build by the peer protocols) and the forwarding =20 > tables (as used by HIP) clear enough. >=20 > A better way to state what we propose might be "Nodes participating =20 > into an overlay forward I1 packets in a hop-by-hop fashion over the =20 > HIP BONE using the forwarding tables, which in turn are built based =20 > on the routing table constructed by the peer protocol for the =20 > overlay." But that would be quite a bunch to engulf at one time. >=20 > > Were I to > > implement RELOAD on top of HIP-BONE, what exactly does this mean? >=20 > [Caveat: I don't know RELOAD nor other peer protocols in detail.] >=20 > > Does this mean that I send a RELOAD CONNECT message and the contents > > of that message are now an I1 instead of ICE candidates? Or would > > RELOAD's CONNECT go away and RELOAD would simply try to=20 > send a message > > directly to a new PeerID via its ORCHID and the HIP-BONE layer would > > then produce an upcall to RELOAD asking that an I1 be=20 > tunneled across > > the overlay? >=20 > I cannot say anything about RELOAD's CONNECT, but my=20 > understanding is =20 > that a forwarding node would look at the next hop ORCHID=20 > based on the =20 > forwarding table, and then pass the packet to the HIP =20 > implementation. The HIP implementation would then detect if=20 > there is =20 > an active HIP association towards that ORCHID. If there is, the I1 =20 > packet is passed over that HIP association. If there are not but =20 > there is a valid locator associated with the next hop ORCHID, then =20 > the I1 packet is passed over IP using the locator. If=20 > neither, there =20 > the forwarding table is faulty, and the HIP layer needs to kick the =20 > peer protocols to rebuild the forwarding table. That is similar to =20 > the case where the IP layer kicks the routing layer whenever=20 > it drops =20 > a packet due to missing route. An open question here is whether and =20 > how to report the error back, i.e., if there should be a function =20 > similar to ICMP. If yes, HIP NOTIFY packets could be used for that =20 > purpose. >=20 > Further note that there are at least two choices of what to use as =20 > index to the forwarding table look up. Either one can use the Peer =20 > ID, presumably carried in a new HIP parameter in the I1 packet, or =20 > one can use the ORCHID, carried in the source HIT field in the I1 =20 > packet. From the high level point of view, both would work equally =20 > well, but as usual the devil may lie in the details. The latter =20 > would be structurally similar to the currently specified HIP =20 > rendezvous service, and has been used in previous suggestions=20 > for HIP-=20 > based overlays. Pekka, If I understand correctly, you are suggesting that there would be HIP forwarding table(s) with next hop ORCHIDs. There may be next hop IP addresses or active HIP tunnels corresponding to each next hop ORCHID. There may be multiple peer protocols populating this HIP table. =20 Then, it seems to be the case that there must be multiple HIP forwarding tables, one for each overlay. I think it has to be so because, unlike routing, where different routing protocols will likely inject forwarding table entries (prefixes) corresponding to separate regions of the IP address space, each HIP-based overlay (and ORCHID space) overlaps the ORCHID range completely. Furthermore, nodes in a DHT will be responsible for portions of the space and these portions will overlap from overlay to overlay. If so, then there is a requirement to be able to look up the right forwarding table from an I1, which I think you are suggesting above in the last paragraph. So the I1 (and probably all HIP packets) needs to carry some metadata about the ORCHID type in use, either in a new parameter or embedded in a certificate. Basically, there needs to be a new namespace in use at the HIP forwarding layer-- the namespace uniquely identifying overlays. This could perhaps be the ORCHID Context ID. =20 Another related question I have is whether you think the legacy application API (based on sockets) would work anymore with ORCHIDs, because if you get a raw ORCHID across the sockets API, you can't tell by inspecting the ORCHID which overlay it belongs to, because the context ID is not visible. It seems that you would need to pass metadata about the ORCHID across the sockets API, so that the node knows which ORCHID-based overlay that it belongs to, or else you need to use LSIs even in the IPv6 case (as suggested by Philip Matthews at the Vancouver meeting). Tom _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Dec 27 08:31:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7spL-0000eE-Ab; Thu, 27 Dec 2007 08:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7spK-0000e8-2T for p2psip@ietf.org; Thu, 27 Dec 2007 08:31:10 -0500 Received: from n2.nomadiclab.com ([2001:14b8:400:101::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7spJ-0008SF-6t for p2psip@ietf.org; Thu, 27 Dec 2007 08:31:10 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 721391F87EA; Thu, 27 Dec 2007 15:31:07 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id D8DA41F87E9; Thu, 27 Dec 2007 15:31:06 +0200 (EET) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049ADA@XCH-NW-5V1.nw.nos.boeing.com> References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> <77F357662F8BFA4CA7074B0410171B6D04049ADA@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A9BA698-3320-459A-9AF7-877183245F0A@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [P2PSIP] New draft: HIP BONE Date: Thu, 27 Dec 2007 15:31:06 +0200 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.753) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> In general, we tried to clarify the proposed relationship between >> HIP and the peer protocols by the architectural analogy [...], >> where we state that HIP acts in a role similar to IP [...] and the >> peer protocols in a role similar to routing protocols [...]. >> A better way to state what we propose might be "Nodes >> participating into an overlay forward I1 packets in a hop-by-hop >> fashion over the HIP BONE using the forwarding tables, which in >> turn are built based on the routing table constructed by the peer >> protocol for the overlay." >> [...] my understanding is that a forwarding node would look at the >> next hop ORCHID based on the forwarding table, and then pass the >> packet to the HIP implementation. The HIP implementation would >> then detect if there is an active HIP association towards that >> ORCHID. If there is, the I1 packet is passed over that HIP >> association. If there are not but there is a valid locator >> associated with the next hop ORCHID, then the I1 packet is passed >> over IP using the locator. >> Further note that there are at least two choices of what to use as >> index to the forwarding table look up: >> 1) one can use the Peer ID, presumably carried in a new HIP >> parameter in the I1 packet, or >> 2) one can use the ORCHID, carried in the source HIT field in the >> I1 packet. > If I understand correctly, you are suggesting that there would be > HIP forwarding table(s) with next hop ORCHIDs. There may be next > hop IP addresses or active HIP tunnels corresponding to each next > hop ORCHID. Yes, thought I'd prefer to say "next hop locators" instead of "next hop IP addresses", since I could imagine such locators also to have other forms, such as UDP tunnels for HIP signalling traffic or such. > There may be multiple peer protocols populating this HIP table. I didn't really think about that. Hence, here we go forward from my previous thinking. > Then, it seems to be the case that there must be multiple HIP > forwarding tables, one for each overlay. [...] Furthermore, nodes > in a DHT will be responsible for portions of the space and these > portions will overlap from overlay to overlay. Yes, you are right. Furthermore, the set of nodes in each overlay may be partially disjoint. > If so, then there is a requirement to be able to look up the right > forwarding table from an I1, which I think you are suggesting above > in the last paragraph. Well, as far as I can see, that depends on the assumptions on the number of partially overlapping overlays. If that number is small, the I could imagine that instead of picking just one forwarding table to use, one could simply replicate the I1 to all overlays in the case the right overlay is not know. However, if replicating an I1, it would most probably make sense to tag it with the names of all overlays to which it is being sent to, or at least denote the primary overlay it was sent to. But the details depend on detail requirements that I don't understand, e.g., what is the exact semantics of having multiple overlays. > So the I1 (and probably all HIP packets) needs to carry some > metadata about the ORCHID type in use, either in a new parameter or > embedded in a certificate. Right; that makes sense once a HIP signalling packet is being forwarded within an overlay. I think a new parameter makes more sense, as it would most probably be more efficient to handle that. For other reasons, I was thinking of a parameter that would carry an ORCHID Context ID. > Basically, there needs to be a new namespace in use at the HIP > forwarding layer -- the namespace > uniquely identifying overlays. This could perhaps be the ORCHID > Context ID. I concur. > Another related question I have is whether you think the legacy > application API (based on sockets) would work anymore with ORCHIDs, > because if you get a raw ORCHID across the sockets API, you can't > tell by inspecting the ORCHID which overlay it belongs to, because > the context ID is not visible. Hmm. The situation may be worse. The case may well be that the app has no information at all about the overlays, so that it may not even be possible to tell the right overlay at all. In such a case my suggestion above, i.e., to send the packet to all overlays simultaneously, might make sense. > It seems that you would need to pass metadata about the ORCHID > across the sockets API, so that the node knows > which ORCHID-based overlay that it belongs to, or else you need to > use LSIs even in the IPv6 case (as suggested by Philip Matthews at > the Vancouver meeting). As far as I can see, that depends on the requirements. If the requirement is simply create a secured connection to the peer if reachable at all, then IMHO it would make sense to try all of the overlays at the same time. As long as the number of overlays is relatively small, the amount of additional traffic will be quite small, and originate from the source, i.e., is not replicated in the network. --Pekka _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 28 02:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J89L3-0004lf-1S; Fri, 28 Dec 2007 02:09:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J89L1-0004di-38 for p2psip@ietf.org; Fri, 28 Dec 2007 02:08:59 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J89L0-0004DU-Ll for p2psip@ietf.org; Fri, 28 Dec 2007 02:08:59 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBS78htT018210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Dec 2007 01:08:47 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBS78hCt004410; Fri, 28 Dec 2007 01:08:43 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBS78gCt004405; Fri, 28 Dec 2007 01:08:42 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Dec 2007 23:08:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] a modular approach for integrating HIP for P2PSIP Date: Thu, 27 Dec 2007 23:08:41 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049ADB@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <477268E1.4050509@uni-tuebingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] a modular approach for integrating HIP for P2PSIP Thread-Index: AchHze7yS7pF4qqpScGn12f6BCg5LwBTyrjQ References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com><476E2B7C.9070601@ericsson.com> <47724ED2.7060508@uni-tuebingen.de><47725398.4000309@ericsson.com> <477268E1.4050509@uni-tuebingen.de> From: "Henderson, Thomas R" To: "Ali Fessi" , "Gonzalo Camarillo" X-OriginalArrivalTime: 28 Dec 2007 07:08:42.0528 (UTC) FILETIME=[7AA20A00:01C84920] X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de]=20 > Sent: Wednesday, December 26, 2007 6:45 AM > To: Gonzalo Camarillo > Cc: P2PSIP Mailing List > Subject: [P2PSIP] a modular approach for integrating HIP for P2PSIP >=20 > Dear Gonzalo, all, >=20 > according to draft-ietf-mmusic-ice, addresses collected for=20 > ICE can be=20 > also "obtained through a tunnel mechanism, such as a Virtual Private=20 > Network (VPN) or Mobile IP (MIP)". >=20 > If i understand correctly (please correct me if i am wrong)=20 > the ORCHID=20 > (alternatively the LSI if the application uses IPv4) is bound=20 > locally to=20 > a virtual interface. So the application can use it the same=20 > way it uses=20 > an IP address obtained by a VPN (or any other IP address,=20 > e.g. obtained=20 > by STUN) >=20 > So is there a reason why HIP ORCHIDs cannot be used in the ICE=20 > candidates list? >=20 > Also the ICE host candidates' sorting process (as described=20 > in Section=20 > 2.3 "Sorting Candidates" in draft-ietf-mmusic-ice) could=20 > recognize the=20 > HIP ORCHID (due to the unique prefix) and give it higher=20 > priority in the=20 > host candidate list if the application should benefit from the HIP=20 > advantages. >=20 > I think that could provide a simple - though modular and flexible -=20 > approach for integrating HIP for P2PSIP (at least for the NAT=20 > traversal=20 > part) >=20 > In other words: >=20 > - the application can easily check whether the host where it=20 > is running=20 > supports HIP. >=20 > - a peer can inform another peer that it supports HIP (using the ICE=20 > candidates list and the priorities given to the addresses). If both=20 > peers support HIP and they are in the same HIP overlay, then they can=20 > (and maybe should) use it. >=20 > - if one of the peer hosts does not support HIP, then the peers will=20 > need to go forward in the ICE host candidate list and use other=20 > addresses for connectivity, e.g. those obtained by STUN. >=20 > I mentioned, this could provide a modular approach for the=20 > NAT traversal=20 > problem. But maybe it could be extended to cope with the=20 > other features=20 > that HIP provides, e.g. mobility and multi-homing. >=20 > Any comments? >=20 If you cannot count on HIP being present below your application, you are probably going to provide the functionality yourself (ICE, mobility support, security) if you want to deploy a successful P2P application. And if so, do you then care much about using HIP if/when it later enters the picture? (see also: IPv6 deployment...) I think the interesting thing for P2PSIP to decide is whether to try to go for an architecture where ICE/mobility handling is (non-optionally) layered below the application so that such components can be reused generally across applications. Specifying it as an option will just lead to it being replicated everywhere. =20 Tom _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Dec 28 02:10:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J89Me-0007qz-H2; Fri, 28 Dec 2007 02:10:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J89Mc-0007qt-Kh for p2psip@ietf.org; Fri, 28 Dec 2007 02:10:38 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J89Mc-0004Xh-7O for p2psip@ietf.org; Fri, 28 Dec 2007 02:10:38 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBS7Aamf021589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Dec 2007 23:10:36 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBS7AaOU008216; Thu, 27 Dec 2007 23:10:36 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBS7AapD008213; Thu, 27 Dec 2007 23:10:36 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Dec 2007 23:10:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: HIP BONE Date: Thu, 27 Dec 2007 23:10:35 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049ADC@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <2A9BA698-3320-459A-9AF7-877183245F0A@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: HIP BONE Thread-Index: AchIjL8rbeYXzIwUSkKUjaYLc3lJDQAjmvhQ References: <476BA8D9.4010203@ericsson.com><20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <12016CE5-4145-4F69-8C1A-BE9A165EEFDD@nomadiclab.com> <77F357662F8BFA4CA7074B0410171B6D04049ADA@XCH-NW-5V1.nw.nos.boeing.com> <2A9BA698-3320-459A-9AF7-877183245F0A@nomadiclab.com> From: "Henderson, Thomas R" To: "Pekka Nikander" X-OriginalArrivalTime: 28 Dec 2007 07:10:35.0951 (UTC) FILETIME=[BE3D03F0:01C84920] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, December 27, 2007 5:31 AM > To: Henderson, Thomas R > Cc: Bruce Lowekamp; P2PSIP Mailing List > Subject: Re: [P2PSIP] New draft: HIP BONE >=20 > > Another related question I have is whether you think the legacy =20 > > application API (based on sockets) would work anymore with=20 > ORCHIDs, =20 > > because if you get a raw ORCHID across the sockets API, you can't =20 > > tell by inspecting the ORCHID which overlay it belongs to, because =20 > > the context ID is not visible. >=20 > Hmm. The situation may be worse. The case may well be that the app =20 > has no information at all about the overlays, so that it may=20 > not even =20 > be possible to tell the right overlay at all. In such a case my =20 > suggestion above, i.e., to send the packet to all overlays =20 > simultaneously, might make sense. >=20 > > It seems that you would need to pass metadata about the ORCHID =20 > > across the sockets API, so that the node knows > > which ORCHID-based overlay that it belongs to, or else you need to =20 > > use LSIs even in the IPv6 case (as suggested by Philip Matthews at =20 > > the Vancouver meeting). >=20 > As far as I can see, that depends on the requirements. If the =20 > requirement is simply create a secured connection to the peer if =20 > reachable at all, then IMHO it would make sense to try all of the =20 > overlays at the same time. As long as the number of overlays is =20 > relatively small, the amount of additional traffic will be quite =20 > small, and originate from the source, i.e., is not replicated in the =20 > network. There may be policy reasons for preferring the use of one overlay over another, though. And, IMO, it seems an inelegant solution akin to replicating IP packets across all interfaces if one does not have a route to the destination. I think we need to be careful not to again conflate identifiers and locators in the architecture, this time with ORCHIDs.=20 Tom _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Dec 31 05:46:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9IAR-00077t-LT; Mon, 31 Dec 2007 05:46:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9IAQ-00070q-Cl for p2psip@ietf.org; Mon, 31 Dec 2007 05:46:46 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9IAP-0000IB-K6 for p2psip@ietf.org; Mon, 31 Dec 2007 05:46:46 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8766B20888; Mon, 31 Dec 2007 11:46:44 +0100 (CET) X-AuditID: c1b4fb3c-b0798bb0000030cf-0c-4778c8940245 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5A9F620487; Mon, 31 Dec 2007 11:46:44 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Dec 2007 11:46:44 +0100 Received: from [159.107.2.36] ([159.107.2.36]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Dec 2007 11:46:42 +0100 Message-ID: <4778C88A.20201@ericsson.com> Date: Mon, 31 Dec 2007 12:46:34 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ali Fessi References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <47724ED2.7060508@uni-tuebingen.de> <47725398.4000309@ericsson.com> <477268E1.4050509@uni-tuebingen.de> In-Reply-To: <477268E1.4050509@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Dec 2007 10:46:43.0784 (UTC) FILETIME=[6EE88C80:01C84B9A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: P2PSIP Mailing List Subject: [P2PSIP] Re: a modular approach for integrating HIP for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Ali, HIP includes an ICE-based NAT traversal mechanism. If two nodes use HIP, they will perform ICE at the HIP level, not at the application level. Using application-level ICE to negotiate the use of HIP between nodes, per your email below, is cumbersome. The use of HIP can be negotiated in simpler ways. With regards to the use of HIP in overlays, the simplest way would be to deploy overlays where all nodes use HIP and overlays where none of the nodes use HIP. However, some people have expressed interest in having mixed overlays where some nodes use HIP while others don't. If people are interested in doing this, we will have to look into ways to negotiate its use within the overlay. Cheers, Gonzalo Ali Fessi wrote: > Dear Gonzalo, all, > > according to draft-ietf-mmusic-ice, addresses collected for ICE can be > also "obtained through a tunnel mechanism, such as a Virtual Private > Network (VPN) or Mobile IP (MIP)". > > If i understand correctly (please correct me if i am wrong) the ORCHID > (alternatively the LSI if the application uses IPv4) is bound locally to > a virtual interface. So the application can use it the same way it uses > an IP address obtained by a VPN (or any other IP address, e.g. obtained > by STUN) > > So is there a reason why HIP ORCHIDs cannot be used in the ICE > candidates list? > > Also the ICE host candidates' sorting process (as described in Section > 2.3 "Sorting Candidates" in draft-ietf-mmusic-ice) could recognize the > HIP ORCHID (due to the unique prefix) and give it higher priority in the > host candidate list if the application should benefit from the HIP > advantages. > > I think that could provide a simple - though modular and flexible - > approach for integrating HIP for P2PSIP (at least for the NAT traversal > part) > > In other words: > > - the application can easily check whether the host where it is running > supports HIP. > > - a peer can inform another peer that it supports HIP (using the ICE > candidates list and the priorities given to the addresses). If both > peers support HIP and they are in the same HIP overlay, then they can > (and maybe should) use it. > > - if one of the peer hosts does not support HIP, then the peers will > need to go forward in the ICE host candidate list and use other > addresses for connectivity, e.g. those obtained by STUN. > > I mentioned, this could provide a modular approach for the NAT traversal > problem. But maybe it could be extended to cope with the other features > that HIP provides, e.g. mobility and multi-homing. > > Any comments? > > Thanks in advance. > > Cheers, > Ali > > Gonzalo Camarillo wrote: >> Hi, >> >>> what is if peers add the HIP ORCHID at the first position of the list >>> of gathered addresses for ICE? >> >> ORCHIDs are identifiers. You need locators (i.e., IP addresses) for >> the ICE process. >> >> Cheers, >> >> Gonzalo >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip