From speermint-bounces@ietf.org Fri Feb 02 10:59:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0nx-0007aK-A3; Fri, 02 Feb 2007 10:58:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0nv-0007Yv-E0 for speermint@ietf.org; Fri, 02 Feb 2007 10:58:23 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0nt-0004RY-LM for speermint@ietf.org; Fri, 02 Feb 2007 10:58:23 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l12FwLhO014469 for ; Fri, 2 Feb 2007 07:58:21 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l12FwHKf014468 for speermint@ietf.org; Fri, 2 Feb 2007 07:58:17 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 2 Feb 2007 07:58:17 -0800 From: David Meyer To: speermint@ietf.org Message-ID: <20070202155817.GA14461@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "But that's not the way it feels" -- Jim Croce, Operator X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0710492734==" Errors-To: speermint-bounces@ietf.org --===============0710492734== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF=20 > Meeting in Prague, Czech Republic=20 > Date: Fri, 02 Feb 2007 00:00:01 -0500 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 68th=20 > IETF Meeting in Prague, Czech Republic: >=20 > February 26th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > February 26th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > February 19th at 9:00 AM ET. >=20 > March 5th: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, March 5th at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, March 19th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_68.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFw1+ZORgD1qCZ2KcRAm4dAJwI7mg5Rw6yw1tmEnln4H0UXNvvagCgi9gX 5hrDV8d7qQOafeuvw25HEAE= =XkMH -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- --===============0710492734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0710492734==-- From speermint-bounces@ietf.org Mon Feb 12 12:47:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfFA-00077L-Sw; Mon, 12 Feb 2007 12:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfFA-000779-7k; Mon, 12 Feb 2007 12:45:36 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGfF8-0002D1-Ru; Mon, 12 Feb 2007 12:45:36 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1CHjK1a023539; Mon, 12 Feb 2007 09:45:26 -0800 From: "Richard Shockey" To: Date: Mon, 12 Feb 2007 12:45:16 -0500 Message-ID: <010401c74ecd$8f7dd880$95201f0a@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.3028 Thread-Index: AcdOzY3BxSi5k/k4QYeSlie9Y3uAOQ== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: enum@ietf.org, speermint@ietf.org Subject: [Speermint] There will not be a Official BOF on PEPPERMINT at IETF Prague X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The IESG has decided not to hold a BOF on PEPPERMINT "at this time". There are many reasons for this, principally scheduling, which is rather complex this cycle. This action does not imply that our problem statement is bad or that there is not a clear indication that there are folks who want to move forward on the work. We all know this work is important and needs to get done. This list will remain open. What I'm going to try and do is see if I can get a room in Prague for an unofficial BOF so we can collectively discuss what the next steps are before Chicago and we resubmit a BOF plan and agenda. Certainly one of the things we should do before Chicago is refine the current Requirements proposals into something more well defined and coherent. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org Skype:"rshockey101" PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 13 11:39:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH0g4-0003mT-DZ; Tue, 13 Feb 2007 11:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH0g2-0003lt-84 for speermint@ietf.org; Tue, 13 Feb 2007 11:38:46 -0500 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH0fz-0005bN-VY for speermint@ietf.org; Tue, 13 Feb 2007 11:38:46 -0500 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l1DGcV3Y022179 for ; Tue, 13 Feb 2007 16:38:31 GMT Subject: [Speermint] Are we done?? From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Tue, 13 Feb 2007 09:47:44 -0700 Message-Id: <1171385264.17141.45.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org After San Diego (or at San Diego), we talked a lot about identifying the basic, necessary concepts of establishing peering. We also talked about identifying the basic requirements for peering. I believe Jean-Francois was working on that. Since then, there have been no further discussions or updates to the drafts. I'm trying to determine what the most likely reason is for the silence. Either, we have already "beat the horse" and well defined the aspects I just mentioned, or we are too far off and we're unsure as to what direction to head next. ...Or, we are all to busy to work on this right now. I'm wondering if we should move these drafts to WGLC to determine if there are any new critical aspects to discuss. Basic question...are we done with the initial drafts? --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 14 13:16:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOel-0006B4-Gi; Wed, 14 Feb 2007 13:15:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOek-0006Au-F3 for speermint@ietf.org; Wed, 14 Feb 2007 13:15:02 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOej-0000QR-8E for speermint@ietf.org; Wed, 14 Feb 2007 13:15:02 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id B2C1EE8D34 for ; Wed, 14 Feb 2007 13:14:28 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 13:14:28 -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 Date: Wed, 14 Feb 2007 13:14:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIw== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 14 Feb 2007 18:14:28.0488 (UTC) FILETIME=[F7551080:01C75063] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Speermint] Use cases and categorization X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Couple questions for folks... We are working on a consolidation of use cases for SPEERMINT - and in that effort, we have acknowledged 3 categories of use cases: Direct, Indirect and Assisted. This falls inline with the terminology draft. With that in mind... 1) Per the definition of a 'Federation' in the terminology draft - "A federation is a group of SPs which agree to receive calls from each other via SIP, and who agree on a set of administrative rules for such calls (settlement, abuse-handling, ...) and the specific rules for the technical details of the interconnection." I read this to mean that any and all of the above peering categorizations involve the use of a Federation. Do we have consensus on that? 2) Should we address any nuances between Enterprises and SPs as it pertains to the above categorizations? =20 I appreciate any and all thoughts on the topics. Adam Uzelac Principal Network Eng./Sr. Manager Converged Arch. Global Crossing 585-255-8916 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 14 18:11:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTHD-0003bv-R3; Wed, 14 Feb 2007 18:11:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTHC-0003bp-Gs for speermint@ietf.org; Wed, 14 Feb 2007 18:11:02 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTHB-0002w5-6h for speermint@ietf.org; Wed, 14 Feb 2007 18:11:02 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1ENB0Dk017812 for ; Wed, 14 Feb 2007 18:11:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Use cases and categorization Date: Wed, 14 Feb 2007 18:11:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAKAl6w References: From: "Rodrig, Benny \(Benny\)" To: "Uzelac, Adam" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Regarding question (2) - Enterprise peering cases should be addressed but I don't think they impact the categorization. John Elwell and I have a draft on enterprise use-cases to be submitted very shortly, and it is in line with the direct/indirect categories. Benny=20 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Wednesday, February 14, 2007 1:14 PM To: speermint@ietf.org Subject: [Speermint] Use cases and categorization Couple questions for folks... We are working on a consolidation of use cases for SPEERMINT - and in that effort, we have acknowledged 3 categories of use cases: Direct, Indirect and Assisted. This falls inline with the terminology draft. With that in mind... 1) Per the definition of a 'Federation' in the terminology draft - "A federation is a group of SPs which agree to receive calls from each other via SIP, and who agree on a set of administrative rules for such calls (settlement, abuse-handling, ...) and the specific rules for the technical details of the interconnection." I read this to mean that any and all of the above peering categorizations involve the use of a Federation. Do we have consensus on that? 2) Should we address any nuances between Enterprises and SPs as it pertains to the above categorizations? =20 I appreciate any and all thoughts on the topics. Adam Uzelac Principal Network Eng./Sr. Manager Converged Arch. Global Crossing 585-255-8916 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 03:35:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHc4f-0007tD-9V; Thu, 15 Feb 2007 03:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHc4e-0007t8-Mu for speermint@ietf.org; Thu, 15 Feb 2007 03:34:40 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHc4d-0007Xq-Bd for speermint@ietf.org; Thu, 15 Feb 2007 03:34:40 -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: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 10:34:37 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization thread-index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyygg References: From: "David Schwartz" To: "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Adam > Couple questions for folks... > > We are working on a consolidation of use cases for SPEERMINT - and in > that effort, we have acknowledged 3 categories of use cases: Direct, > Indirect and Assisted. This falls inline with the terminology draft. > With that in mind... > > 1) Per the definition of a 'Federation' in the terminology draft - "A > federation is a group of SPs which agree to receive calls from each > other via SIP, and who agree on a set of administrative rules for such > calls (settlement, abuse-handling, ...) and the specific rules for the > technical details of the interconnection." I read this to mean that any > and all of the above peering categorizations involve the use of a > Federation. Do we have consensus on that? > > 2) Should we address any nuances between Enterprises and SPs as it > pertains to the above categorizations? =20 I have always preferred the term aggregator to service provider as the point to focus on is that peering involves interconnection between two (or more) parties that represent many more entities. With that in mind I see no reason to differentiate between SP's and enterprises (some of which are larger than many SP's) since both are performing the "aggregation" function. IMHO, the relationship between the "aggregator" (SP or enterprise) and its subscriber base should be of no concern to us. D. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 05:27:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdpG-00030i-0L; Thu, 15 Feb 2007 05:26:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdpE-00030b-Ri for speermint@ietf.org; Thu, 15 Feb 2007 05:26:52 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHdpD-0003hR-Et for speermint@ietf.org; Thu, 15 Feb 2007 05:26:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 11:26:16 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GA= From: "Stastny Richard" To: "David Schwartz" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org To Adam and David, > > > > 1) Per the definition of a 'Federation' in the terminology draft - "A > > federation is a group of SPs which agree to receive calls from each > > other via SIP, and who agree on a set of administrative rules for such > > calls (settlement, abuse-handling, ...) and the specific rules for the > > technical details of the interconnection." I read this to mean that > any > > and all of the above peering categorizations involve the use of a > > Federation. Do we have consensus on that? IMO the federation encompasses all: On one hand you have a federation of two (in a pure bilateral agreement) and on the other hand you may have a federation of all service providers for a global federation > > > > 2) Should we address any nuances between Enterprises and SPs as it > > pertains to the above categorizations? >=20 > I have always preferred the term aggregator to service provider as the > point to focus on is that peering involves interconnection between two > (or more) parties that represent many more entities. With that in mind I > see no reason to differentiate between SP's and enterprises (some of > which are larger than many SP's) since both are performing the > "aggregation" function. >=20 > IMHO, the relationship between the "aggregator" (SP or enterprise) and > its subscriber base should be of no concern to us. >=20 I am not so sure: technically yes, but not legally At least in the current legal regime (PSTN) enterprises are below service providers and numbers are assigned from NRA to service providers, which in turn assign numbers to subscribers. SP interconnect with NNIs. Enterprises are connected via UNIs. There are also differences in number portability. Since regulations claim to be "technology" neutral, we have to be careful. Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 06:05:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHeQg-00047x-4r; Thu, 15 Feb 2007 06:05:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHeQf-00047q-En for speermint@ietf.org; Thu, 15 Feb 2007 06:05:33 -0500 Received: from bzq-25-94-44.static.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHeQe-00032e-0W for speermint@ietf.org; Thu, 15 Feb 2007 06:05:33 -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: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 13:05:30 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550221C971@isr-jlm-mail.Kayote.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization thread-index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GAAAPA14A== References: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com> <32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> From: "David Schwartz" To: "Stastny Richard" , "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Richard. I am not sure I understand why application based peering (which is what I thought SPEERMINT was all about) needs to be concerned with UNI vs. NNI considerations. As for number portability this brings up many of the "ownership" issues that have been discussed before. In many (most?) cases SP's are not carriers of record for the numbers so in a sense they do not "own" the numbers they then assign to the enterprise. Differentiating between the two based on levels down the "ownership" tree is artificial. Cheers, D. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, February 15, 2007 12:26 PM To: David Schwartz; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Use cases and categorization To Adam and David, > > > > 1) Per the definition of a 'Federation' in the terminology draft - "A > > federation is a group of SPs which agree to receive calls from each > > other via SIP, and who agree on a set of administrative rules for such > > calls (settlement, abuse-handling, ...) and the specific rules for the > > technical details of the interconnection." I read this to mean that > any > > and all of the above peering categorizations involve the use of a > > Federation. Do we have consensus on that? IMO the federation encompasses all: On one hand you have a federation of two (in a pure bilateral agreement) and on the other hand you may have a federation of all service providers for a global federation > > > > 2) Should we address any nuances between Enterprises and SPs as it > > pertains to the above categorizations? >=20 > I have always preferred the term aggregator to service provider as the > point to focus on is that peering involves interconnection between two > (or more) parties that represent many more entities. With that in mind I > see no reason to differentiate between SP's and enterprises (some of > which are larger than many SP's) since both are performing the > "aggregation" function. >=20 > IMHO, the relationship between the "aggregator" (SP or enterprise) and > its subscriber base should be of no concern to us. >=20 I am not so sure: technically yes, but not legally At least in the current legal regime (PSTN) enterprises are below service providers and numbers are assigned from NRA to service providers, which in turn assign numbers to subscribers. SP interconnect with NNIs. Enterprises are connected via UNIs. There are also differences in number portability. Since regulations claim to be "technology" neutral, we have to be careful. Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 06:28:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHemF-0001tj-EO; Thu, 15 Feb 2007 06:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHemD-0001tK-La for speermint@ietf.org; Thu, 15 Feb 2007 06:27:49 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHemC-0006c5-51 for speermint@ietf.org; Thu, 15 Feb 2007 06:27:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 12:27:15 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646BC6@oefeg-s04.oefeg.loc> In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550221C971@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GAAAPA14AAA1sVg From: "Stastny Richard" To: "David Schwartz" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi David, Yes and no For pure Speermint issues (peering with AoR) this is not an issue, as is NP not an issue And the term carrier-of-record is only used with E.164 numbers But as numbering always pops up in Speermint too, it may be an issue > -----Original Message----- > I am not sure I understand why application based peering (which is what > I thought SPEERMINT was all about) needs to be concerned with UNI vs. > NNI considerations. >=20 > As for number portability this brings up many of the "ownership" issues > that have been discussed before. In many (most?) cases SP's are not > carriers of record for the numbers so in a sense they do not "own" the > numbers they then assign to the enterprise. Differentiating between the > two based on levels down the "ownership" tree is artificial. >=20 First, nobody "owns" a number Numbers are allocated to SP and assigned to end-users Enterprises are also end-users like normal subscribers, e.g. in Austria there is no difference in principal I have the number +43 1 9793321 at home and may decide tomorrow to add a PBX with two digits in addition such as +43 1 9793321 xx I can port this number (the pilot) to IP (it is, in fact) and run a SER. I am now a SP for the +43 1 9793321 xx number range, am I? What is not possible is that e.g. +43 1 9793321 24 is ported to another SP. What is now the difference between Siemens, IBM and my home enterprise? The size? Or is anybody running a proxy a SP? Can I port a number to myself? Or do we have different rules for numbers on IP and on the PSTN? As I said, this is not (only) a technical issue, it is mainly a legal issue. Cheers Richard >=20 > D. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, February 15, 2007 12:26 PM > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > To Adam and David, >=20 > > > > > > 1) Per the definition of a 'Federation' in the terminology draft - > "A > > > federation is a group of SPs which agree to receive calls from each > > > other via SIP, and who agree on a set of administrative rules for > such > > > calls (settlement, abuse-handling, ...) and the specific rules for > the > > > technical details of the interconnection." I read this to mean that > > any > > > and all of the above peering categorizations involve the use of a > > > Federation. Do we have consensus on that? >=20 > IMO the federation encompasses all: > On one hand you have a federation of two (in a pure bilateral agreement) > and on the other hand you may have a federation of all service providers > for a global federation >=20 >=20 > > > > > > 2) Should we address any nuances between Enterprises and SPs as it > > > pertains to the above categorizations? > > > > I have always preferred the term aggregator to service provider as the > > point to focus on is that peering involves interconnection between two > > (or more) parties that represent many more entities. With that in mind > I > > see no reason to differentiate between SP's and enterprises (some of > > which are larger than many SP's) since both are performing the > > "aggregation" function. > > > > IMHO, the relationship between the "aggregator" (SP or enterprise) and > > its subscriber base should be of no concern to us. > > >=20 > I am not so sure: technically yes, but not legally >=20 > At least in the current legal regime (PSTN) enterprises are below > service > providers and numbers are assigned from NRA to service providers, which > in > turn assign numbers to subscribers. SP interconnect with NNIs. > Enterprises are connected via UNIs. There are also differences in number > portability. >=20 > Since regulations claim to be "technology" neutral, we have to be > careful. >=20 > Richard >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 08:18:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgUE-0002zU-PN; Thu, 15 Feb 2007 08:17:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgUD-0002zP-Uh for speermint@ietf.org; Thu, 15 Feb 2007 08:17:21 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHgUC-0003d8-LS for speermint@ietf.org; Thu, 15 Feb 2007 08:17:21 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 5BBB0E896E; Thu, 15 Feb 2007 08:17:10 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 08:17:10 -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: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 08:17:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAKAl6wAB3NspA= References: From: "Uzelac, Adam" To: "Rodrig, Benny (Benny)" X-OriginalArrivalTime: 15 Feb 2007 13:17:10.0271 (UTC) FILETIME=[9956E8F0:01C75103] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Generally speaking, what are the differences between the use cases that you have captured versus the use cases that have already been captured? At an interim Speermint meeting last summer (Philly) there was some rather lively discussions on this point, as well as in San Diego. =20 Thanks in advance. -AU=20 > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com]=20 > Sent: Wednesday, February 14, 2007 6:11 PM > To: Uzelac, Adam > Cc: speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Regarding question (2) - Enterprise peering cases should be=20 > addressed but I don't think they impact the categorization.=20 > John Elwell and I have a draft on enterprise use-cases to be=20 > submitted very shortly, and it is in line with the=20 > direct/indirect categories. >=20 > Benny=20 >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, February 14, 2007 1:14 PM > To: speermint@ietf.org > Subject: [Speermint] Use cases and categorization >=20 > Couple questions for folks... >=20 > We are working on a consolidation of use cases for SPEERMINT=20 > - and in that effort, we have acknowledged 3 categories of=20 > use cases: Direct, Indirect and Assisted. This falls inline=20 > with the terminology draft. > With that in mind... >=20 > 1) Per the definition of a 'Federation' in the terminology=20 > draft - "A federation is a group of SPs which agree to=20 > receive calls from each other via SIP, and who agree on a set=20 > of administrative rules for such calls (settlement,=20 > abuse-handling, ...) and the specific rules for the technical=20 > details of the interconnection." I read this to mean that=20 > any and all of the above peering categorizations involve the=20 > use of a Federation. Do we have consensus on that? >=20 > 2) Should we address any nuances between Enterprises and SPs=20 > as it pertains to the above categorizations? =20 >=20 > I appreciate any and all thoughts on the topics. >=20 > Adam Uzelac > Principal Network Eng./Sr. Manager Converged Arch. > Global Crossing > 585-255-8916 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 08:28:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgf7-0003cq-7O; Thu, 15 Feb 2007 08:28:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgf5-0003cb-EY for speermint@ietf.org; Thu, 15 Feb 2007 08:28:35 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHgf4-0005vi-5n for speermint@ietf.org; Thu, 15 Feb 2007 08:28:35 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id DD0E1E94D2; Thu, 15 Feb 2007 08:28:33 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 08:28:33 -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: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 08:28:32 -0500 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GAABkxwQA== References: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com> <32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> From: "Uzelac, Adam" To: "Stastny Richard" , "David Schwartz" , X-OriginalArrivalTime: 15 Feb 2007 13:28:33.0767 (UTC) FILETIME=[30BC1F70:01C75105] X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard, Very interesting with the NNI versus UNI analogy and phone numbers. With a focus on the NA market - allow me to look more into this NNI versus UNI analogy as it pertains to the Speermint. Level3 and Global Crossing (two SPs) exchanging traffic is, I believe, a NNI scenario. Take any Enterprise and any SP, and we have ourselves a UNI scenario. Now what about the gray areas? We could possibly categorize some non-LERG SPs (or "Aggregators") as only accessible via an UNI due to the fact that they are not a CLEC/LEC/IXC/etc. I think that it could be a very slippery slope. =20 For this work we are doing here, I don't think we should make a distinction. -AU > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, February 15, 2007 5:26 AM > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > To Adam and David, >=20 > > > > > > 1) Per the definition of a 'Federation' in the terminology draft - > "A > > > federation is a group of SPs which agree to receive calls=20 > from each=20 > > > other via SIP, and who agree on a set of administrative rules for > such > > > calls (settlement, abuse-handling, ...) and the specific rules for > the > > > technical details of the interconnection." I read this=20 > to mean that > > any > > > and all of the above peering categorizations involve the use of a=20 > > > Federation. Do we have consensus on that? >=20 > IMO the federation encompasses all: > On one hand you have a federation of two (in a pure bilateral=20 > agreement) and on the other hand you may have a federation of=20 > all service providers for a global federation >=20 >=20 > > > > > > 2) Should we address any nuances between Enterprises and=20 > SPs as it=20 > > > pertains to the above categorizations? > >=20 > > I have always preferred the term aggregator to service=20 > provider as the=20 > > point to focus on is that peering involves interconnection=20 > between two=20 > > (or more) parties that represent many more entities. With=20 > that in mind > I > > see no reason to differentiate between SP's and enterprises=20 > (some of=20 > > which are larger than many SP's) since both are performing the=20 > > "aggregation" function. > >=20 > > IMHO, the relationship between the "aggregator" (SP or=20 > enterprise) and=20 > > its subscriber base should be of no concern to us. > >=20 >=20 > I am not so sure: technically yes, but not legally >=20 > At least in the current legal regime (PSTN) enterprises are=20 > below service providers and numbers are assigned from NRA to=20 > service providers, which in turn assign numbers to=20 > subscribers. SP interconnect with NNIs. > Enterprises are connected via UNIs. There are also=20 > differences in number portability. >=20 > Since regulations claim to be "technology" neutral, we have=20 > to be careful. >=20 > Richard >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 09:19:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHhRi-0005oS-Ji; Thu, 15 Feb 2007 09:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHhRg-0005o6-Vl for speermint@ietf.org; Thu, 15 Feb 2007 09:18:48 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHhRf-0004Bo-EG for speermint@ietf.org; Thu, 15 Feb 2007 09:18:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 15:18:14 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646BCD@oefeg-s04.oefeg.loc> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GAABkxwQAAAlE9g From: "Stastny Richard" To: "Uzelac, Adam" , "David Schwartz" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, >=20 > Very interesting with the NNI versus UNI analogy and phone numbers. > With a focus on the NA market - allow me to look more into this NNI > versus UNI analogy as it pertains to the Speermint. Level3 and Global > Crossing (two SPs) exchanging traffic is, I believe, a NNI scenario. > Take any Enterprise and any SP, and we have ourselves a UNI scenario. > Now what about the gray areas? We could possibly categorize some > non-LERG SPs (or "Aggregators") as only accessible via an UNI due to the > fact that they are not a CLEC/LEC/IXC/etc. I think that it could be a > very slippery slope. Indeed We have basically three major scenarios: -Interconnection of SP (Carrier-of-Records, CLEC/LEC/IXC,=20 whatever you name it) direct or via aggregators -Interconnections of SP with end-users having proxies This is the UNI the SIP Forum already specified -Interconnections of end-users having proxies, e.g. enterprises or corporations (small and large), direct or via aggregators In this case we have in addition to look at the requirements from them These where e.g. articulated at TISPAN from ECMA TC32/TC17 They want to build so-called NGCN (C for corporate), which may both interconnect with SPs, but also directly between them, in all combinations > For this work we are doing here, I don't think we should make a > distinction. Now, as long as we stick to our charter and keep E.164 numbers out of the picture and use only SIP AoRs, we do not need to make a distinction, because we only talk about administrative domains But some people here say (and I know them all ,-), in practice we deal only with the mapping from E.164 numbers to ingress points in "networks" In this case this is an issue and we have to make a distinction Richard >=20 > -AU >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, February 15, 2007 5:26 AM > > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > > Subject: RE: [Speermint] Use cases and categorization > > > > To Adam and David, > > > > > > > > > > 1) Per the definition of a 'Federation' in the terminology draft - > > "A > > > > federation is a group of SPs which agree to receive calls > > from each > > > > other via SIP, and who agree on a set of administrative rules for > > such > > > > calls (settlement, abuse-handling, ...) and the specific rules for > > the > > > > technical details of the interconnection." I read this > > to mean that > > > any > > > > and all of the above peering categorizations involve the use of a > > > > Federation. Do we have consensus on that? > > > > IMO the federation encompasses all: > > On one hand you have a federation of two (in a pure bilateral > > agreement) and on the other hand you may have a federation of > > all service providers for a global federation > > > > > > > > > > > > 2) Should we address any nuances between Enterprises and > > SPs as it > > > > pertains to the above categorizations? > > > > > > I have always preferred the term aggregator to service > > provider as the > > > point to focus on is that peering involves interconnection > > between two > > > (or more) parties that represent many more entities. With > > that in mind > > I > > > see no reason to differentiate between SP's and enterprises > > (some of > > > which are larger than many SP's) since both are performing the > > > "aggregation" function. > > > > > > IMHO, the relationship between the "aggregator" (SP or > > enterprise) and > > > its subscriber base should be of no concern to us. > > > > > > > I am not so sure: technically yes, but not legally > > > > At least in the current legal regime (PSTN) enterprises are > > below service providers and numbers are assigned from NRA to > > service providers, which in turn assign numbers to > > subscribers. SP interconnect with NNIs. > > Enterprises are connected via UNIs. There are also > > differences in number portability. > > > > Since regulations claim to be "technology" neutral, we have > > to be careful. > > > > Richard > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 10:43:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHilB-0001lO-CB; Thu, 15 Feb 2007 10:43:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHilA-0001k7-0M for speermint@ietf.org; Thu, 15 Feb 2007 10:43:00 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHikn-0002DY-40 for speermint@ietf.org; Thu, 15 Feb 2007 10:42:58 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2007 10:42:37 -0500 X-IronPort-AV: i="4.14,176,1170651600"; d="scan'208"; a="114004323:sNHT47817920" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1FFgaFk031622; Thu, 15 Feb 2007 10:42:36 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1FFgaOA015306; Thu, 15 Feb 2007 10:42:36 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 10:42:36 -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: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 10:42:35 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3029D3790@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAs0pjw References: From: "Michael Hammer \(mhammer\)" To: "Uzelac, Adam" , X-OriginalArrivalTime: 15 Feb 2007 15:42:36.0617 (UTC) FILETIME=[EAA5A390:01C75117] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1864; t=1171554156; x=1172418156; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Use=20cases=20and=20categorization |Sender:=20 |To:=20=22Uzelac, =20Adam=22=20, =20; bh=DnGMQeKHXEkuc0kydgwZjmcIgpKq6vT4UAOKN9Dsu94=; b=pVLLUifEkE6Y1ZAyh/i95lMNm5FYIwDMZcX0ANgmWuCXVEpsCuzBDPglw7T47pBaqZ8RpAUp 6/+EODKd89+IVyufMcaep6wwlLOcOooEC/Pb3X4QyY7hm5TP318h6xDZ; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, February 14, 2007 1:14 PM > To: speermint@ietf.org > Subject: [Speermint] Use cases and categorization >=20 > Couple questions for folks... >=20 > We are working on a consolidation of use cases for SPEERMINT=20 > - and in that effort, we have acknowledged 3 categories of=20 > use cases: Direct, Indirect and Assisted. This falls inline=20 > with the terminology draft. > With that in mind... >=20 > 1) Per the definition of a 'Federation' in the terminology=20 > draft - "A federation is a group of SPs which agree to=20 > receive calls from each other via SIP, and who agree on a set=20 > of administrative rules for such calls (settlement,=20 > abuse-handling, ...) and the specific rules for the technical=20 > details of the interconnection." I read this to mean that=20 > any and all of the above peering categorizations involve the=20 > use of a Federation. Do we have consensus on that? >=20 > 2) Should we address any nuances between Enterprises and SPs=20 > as it pertains to the above categorizations? =20 I would consider this an implementation detail. The "charter" for the federation can cover details as this or even any arrangements as to whether calls are billed or not, and if so, how; and other details of the business layer overlayed on top of the basic connectivity possibilities. Such business details can be a tarball. Best not to go there. Mike >=20 > I appreciate any and all thoughts on the topics. >=20 > Adam Uzelac > Principal Network Eng./Sr. Manager Converged Arch. > Global Crossing > 585-255-8916 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 11:24:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjOX-00012P-M6; Thu, 15 Feb 2007 11:23:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjOV-00011C-Ps for speermint@ietf.org; Thu, 15 Feb 2007 11:23:39 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHjOT-0005Hz-5C for speermint@ietf.org; Thu, 15 Feb 2007 11:23:38 -0500 Received: from MA0034AVEXU1.global.avaya.com (h135-35-75-7.avaya.com [135.35.75.7]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1FGNWcM005390 for ; Thu, 15 Feb 2007 11:23:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Use cases and categorization Date: Thu, 15 Feb 2007 11:23:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAKAl6wAB3NspAABj49gA== References: From: "Rodrig, Benny \(Benny\)" To: "Uzelac, Adam" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, The enterprise peering use cases we have captured are actually similar to service-provider cases and don't show a major difference, but only potential differences in some details e.g. regulatory aspects and the possibility of using low-granularity number ranges for routing.=20 Benny -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Thursday, February 15, 2007 8:17 AM To: Rodrig, Benny (Benny) Cc: speermint@ietf.org Subject: RE: [Speermint] Use cases and categorization Generally speaking, what are the differences between the use cases that you have captured versus the use cases that have already been captured? At an interim Speermint meeting last summer (Philly) there was some rather lively discussions on this point, as well as in San Diego. =20 Thanks in advance. -AU=20 > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > Sent: Wednesday, February 14, 2007 6:11 PM > To: Uzelac, Adam > Cc: speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Regarding question (2) - Enterprise peering cases should be addressed=20 > but I don't think they impact the categorization. > John Elwell and I have a draft on enterprise use-cases to be submitted > very shortly, and it is in line with the direct/indirect categories. >=20 > Benny >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, February 14, 2007 1:14 PM > To: speermint@ietf.org > Subject: [Speermint] Use cases and categorization >=20 > Couple questions for folks... >=20 > We are working on a consolidation of use cases for SPEERMINT > - and in that effort, we have acknowledged 3 categories of use cases:=20 > Direct, Indirect and Assisted. This falls inline with the terminology > draft. > With that in mind... >=20 > 1) Per the definition of a 'Federation' in the terminology draft - "A=20 > federation is a group of SPs which agree to receive calls from each=20 > other via SIP, and who agree on a set of administrative rules for such > calls (settlement, abuse-handling, ...) and the specific rules for the > technical details of the interconnection." I read this to mean that=20 > any and all of the above peering categorizations involve the use of a=20 > Federation. Do we have consensus on that? >=20 > 2) Should we address any nuances between Enterprises and SPs as it=20 > pertains to the above categorizations? >=20 > I appreciate any and all thoughts on the topics. >=20 > Adam Uzelac > Principal Network Eng./Sr. Manager Converged Arch. > Global Crossing > 585-255-8916 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Feb 15 21:16:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHscp-0005WW-Re; Thu, 15 Feb 2007 21:15:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHsco-0005WP-Mz for speermint@ietf.org; Thu, 15 Feb 2007 21:15:02 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHscn-0008UH-Cx for speermint@ietf.org; Thu, 15 Feb 2007 21:15:02 -0500 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l1G2F0W29831 for ; Thu, 15 Feb 2007 21:15:00 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007021521152125100 for ; Thu, 15 Feb 2007 21:15:21 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 21:15:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Feb 2007 21:15:21 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-haluska-sipping-directory-assistance-02.txt Thread-Index: AcdRcE9wOoS2ccvDSzeMFgaV4I0OrQ== From: "Haluska, John J" To: X-OriginalArrivalTime: 16 Feb 2007 02:15:21.0601 (UTC) FILETIME=[4F8A7710:01C75170] X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Speermint] draft-haluska-sipping-directory-assistance-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1236998196==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1236998196== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75170.4F77DEF6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75170.4F77DEF6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, We are seeking comments on the latest revision of = draft-haluska-sipping-directory-assistance-02.txt This revision goes into much more discussion about applying specific SIP = mechanisms for these kinds of services. In addition to specific needs of providing Directory Assistance type = services, this draft also discusses several inter provider scenarios = which might be more generally applicable to other types of services = which might be provided on a similar basis (e.g. by specialized service = providers). I'm wondering if such scenarios might be interesting to the = SPEERMINT working group. Also, we'd appreciate any comments on our = approaches. Until it is available in the ID repository, it is available at ftp://ftp.research.telcordia.com/pub/world/haluska/draft-haluska-sipping-= directory-assistance-02.txt Thanks much John Haluska ------_=_NextPart_001_01C75170.4F77DEF6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-haluska-sipping-directory-assistance-02.txt

Hello All,


We are seeking comments on the latest revision of = draft-haluska-sipping-directory-assistance-02.txt

This revision goes into much more discussion about applying specific SIP = mechanisms for these kinds of services.

In addition to specific needs of providing Directory Assistance type = services, this draft also discusses several inter provider scenarios = which might be more generally applicable to other types of services = which might be provided on a similar basis (e.g. by specialized service = providers). I'm wondering if such scenarios might be interesting to the = SPEERMINT working group. Also, we'd appreciate any comments on our = approaches.


Until it is available in the ID repository, it is available at

ftp://ftp.research.telcordia.com/pub= /world/haluska/draft-haluska-sipping-directory-assistance-02.txt


Thanks much

John Haluska

------_=_NextPart_001_01C75170.4F77DEF6-- --===============1236998196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1236998196==-- From speermint-bounces@ietf.org Thu Feb 15 21:20:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHshk-0004bq-GW; Thu, 15 Feb 2007 21:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHshi-0004be-JG for speermint@ietf.org; Thu, 15 Feb 2007 21:20:06 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHshh-0000pu-CX for speermint@ietf.org; Thu, 15 Feb 2007 21:20:06 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 15 Feb 2007 18:20:05 -0800 X-IronPort-AV: i="4.14,178,1170662400"; d="scan'208"; a="676182971:sNHT48586952" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Feb 2007 21:20:03 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280764242C@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Architecture and Message flows drafts Thread-index: AcdRcPdXdeapOZVrR1C9cnchBN6Png== From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Speermint] Architecture and Message flows drafts X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello, I'm in the process of updating these two drafts. If you have any comments, let me know before the deadline. Regards, Reinaldo _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 00:34:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHvjc-0001ZD-5l; Fri, 16 Feb 2007 00:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHvja-0001Yv-Ra for speermint@ietf.org; Fri, 16 Feb 2007 00:34:14 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHvjZ-0000Xr-EK for speermint@ietf.org; Fri, 16 Feb 2007 00:34:14 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l1G5Xh8t022250; Thu, 15 Feb 2007 23:34:05 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 23:33:57 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 06:33:55 +0100 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: [Speermint] Use cases and categorization Date: Fri, 16 Feb 2007 06:33:54 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180CEE4D6@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GAABkxwQAAh+HKg References: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com><32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> From: "Drage, Keith \(Keith\)" To: "Uzelac, Adam" , "Stastny Richard" , "David Schwartz" , X-OriginalArrivalTime: 16 Feb 2007 05:33:55.0997 (UTC) FILETIME=[0D1304D0:01C7518C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org How do you come to the conclusion that=20 > Take any Enterprise and any SP, and we have ourselves a UNI scenario. ? That may be the status quo with the ISDN at the moment, where the distinction is enforced by a different protocol, but when we move to a SIP environment, the difference to me seems more regulatory than technical. A public network operator is different from a private network operator only because the regulatory regime defines a class called public network operator. Or do you actually identify something technical? Regards Keith > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: 15 February 2007 13:29 > To: Stastny Richard; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Richard, >=20 > Very interesting with the NNI versus UNI analogy and phone numbers. > With a focus on the NA market - allow me to look more into=20 > this NNI versus UNI analogy as it pertains to the Speermint. =20 > Level3 and Global Crossing (two SPs) exchanging traffic is, I=20 > believe, a NNI scenario. > Take any Enterprise and any SP, and we have ourselves a UNI scenario. > Now what about the gray areas? We could possibly categorize=20 > some non-LERG SPs (or "Aggregators") as only accessible via=20 > an UNI due to the fact that they are not a CLEC/LEC/IXC/etc. =20 > I think that it could be a very slippery slope. =20 >=20 > For this work we are doing here, I don't think we should make=20 > a distinction. >=20 > -AU >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, February 15, 2007 5:26 AM > > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > > Subject: RE: [Speermint] Use cases and categorization > >=20 > > To Adam and David, > >=20 > > > > > > > > 1) Per the definition of a 'Federation' in the=20 > terminology draft - > > "A > > > > federation is a group of SPs which agree to receive calls > > from each > > > > other via SIP, and who agree on a set of administrative=20 > rules for > > such > > > > calls (settlement, abuse-handling, ...) and the=20 > specific rules for > > the > > > > technical details of the interconnection." I read this > > to mean that > > > any > > > > and all of the above peering categorizations involve=20 > the use of a=20 > > > > Federation. Do we have consensus on that? > >=20 > > IMO the federation encompasses all: > > On one hand you have a federation of two (in a pure bilateral > > agreement) and on the other hand you may have a federation of all=20 > > service providers for a global federation > >=20 > >=20 > > > > > > > > 2) Should we address any nuances between Enterprises and > > SPs as it > > > > pertains to the above categorizations? > > >=20 > > > I have always preferred the term aggregator to service > > provider as the > > > point to focus on is that peering involves interconnection > > between two > > > (or more) parties that represent many more entities. With > > that in mind > > I > > > see no reason to differentiate between SP's and enterprises > > (some of > > > which are larger than many SP's) since both are performing the=20 > > > "aggregation" function. > > >=20 > > > IMHO, the relationship between the "aggregator" (SP or > > enterprise) and > > > its subscriber base should be of no concern to us. > > >=20 > >=20 > > I am not so sure: technically yes, but not legally > >=20 > > At least in the current legal regime (PSTN) enterprises are below=20 > > service providers and numbers are assigned from NRA to service=20 > > providers, which in turn assign numbers to subscribers. SP=20 > > interconnect with NNIs. > > Enterprises are connected via UNIs. There are also differences in=20 > > number portability. > >=20 > > Since regulations claim to be "technology" neutral, we have to be=20 > > careful. > >=20 > > Richard > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 10:49:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI5Jk-0007Fo-Aa; Fri, 16 Feb 2007 10:48:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI5Jj-0007Ff-1C for speermint@ietf.org; Fri, 16 Feb 2007 10:48:11 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI5Jh-0004Zd-KN for speermint@ietf.org; Fri, 16 Feb 2007 10:48:11 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id DAF92E95C6; Fri, 16 Feb 2007 10:47:58 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 10:47:58 -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: [Speermint] Use cases and categorization Date: Fri, 16 Feb 2007 10:47:54 -0500 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180CEE4D6@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAAPe1GAABkxwQAAh+HKgAA+zzqA= References: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com><32755D354E6B65498C3BD9FD496C7D46646BC5@oefeg-s04.oefeg.loc> <5D1A7985295922448D5550C94DE29180CEE4D6@DEEXC1U01.de.lucent.com> From: "Uzelac, Adam" To: "Drage, Keith (Keith)" , "Stastny Richard" , "David Schwartz" , X-OriginalArrivalTime: 16 Feb 2007 15:47:58.0688 (UTC) FILETIME=[D5078600:01C751E1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Keith, Absolutely nothing technical in the comments I made. ;) Some more thoughts...the NNI/UNI scenarios are within the context of E164 addressing and regulatory rule-sets. Because of that context, it's really out of scope for Speermint. If you remove the regulatory context, then I agree with you 100% my statement "Take any Enterprise and any SP, and we have ourselves a UNI scenario." makes no sense. On a bit of a different topic, I have recently been trying to understand the utter lack of engaged folks in this working group. I don't believe it's due to a lack of "sip peering" in the world. Could it be that the technical discussions often become clouded with non-technical (regulatory, business) requirements? Could it be explained by a lack of non-technical appreciation within the discussions, therefore any solutions are immediately marginalized? My intention is not to support the regulatory regime, rather to understand the lack of engagement. Let the flames begin. -AU > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Friday, February 16, 2007 12:34 AM > To: Uzelac, Adam; Stastny Richard; David Schwartz; speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > How do you come to the conclusion that=20 >=20 > > Take any Enterprise and any SP, and we have ourselves a UNI=20 > scenario. >=20 > ? >=20 > That may be the status quo with the ISDN at the moment, where=20 > the distinction is enforced by a different protocol, but when=20 > we move to a SIP environment, the difference to me seems more=20 > regulatory than technical. >=20 > A public network operator is different from a private network=20 > operator only because the regulatory regime defines a class=20 > called public network operator. >=20 > Or do you actually identify something technical? >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: 15 February 2007 13:29 > > To: Stastny Richard; David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Use cases and categorization > >=20 > > Richard, > >=20 > > Very interesting with the NNI versus UNI analogy and phone numbers. > > With a focus on the NA market - allow me to look more into this NNI=20 > > versus UNI analogy as it pertains to the Speermint. > > Level3 and Global Crossing (two SPs) exchanging traffic is,=20 > I believe,=20 > > a NNI scenario. > > Take any Enterprise and any SP, and we have ourselves a UNI=20 > scenario. > > Now what about the gray areas? We could possibly categorize some=20 > > non-LERG SPs (or "Aggregators") as only accessible via an=20 > UNI due to=20 > > the fact that they are not a CLEC/LEC/IXC/etc. > > I think that it could be a very slippery slope. =20 > >=20 > > For this work we are doing here, I don't think we should make a=20 > > distinction. > >=20 > > -AU > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Thursday, February 15, 2007 5:26 AM > > > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > > > Subject: RE: [Speermint] Use cases and categorization > > >=20 > > > To Adam and David, > > >=20 > > > > > > > > > > 1) Per the definition of a 'Federation' in the > > terminology draft - > > > "A > > > > > federation is a group of SPs which agree to receive calls > > > from each > > > > > other via SIP, and who agree on a set of administrative > > rules for > > > such > > > > > calls (settlement, abuse-handling, ...) and the > > specific rules for > > > the > > > > > technical details of the interconnection." I read this > > > to mean that > > > > any > > > > > and all of the above peering categorizations involve > > the use of a > > > > > Federation. Do we have consensus on that? > > >=20 > > > IMO the federation encompasses all: > > > On one hand you have a federation of two (in a pure bilateral > > > agreement) and on the other hand you may have a federation of all=20 > > > service providers for a global federation > > >=20 > > >=20 > > > > > > > > > > 2) Should we address any nuances between Enterprises and > > > SPs as it > > > > > pertains to the above categorizations? > > > >=20 > > > > I have always preferred the term aggregator to service > > > provider as the > > > > point to focus on is that peering involves interconnection > > > between two > > > > (or more) parties that represent many more entities. With > > > that in mind > > > I > > > > see no reason to differentiate between SP's and enterprises > > > (some of > > > > which are larger than many SP's) since both are performing the=20 > > > > "aggregation" function. > > > >=20 > > > > IMHO, the relationship between the "aggregator" (SP or > > > enterprise) and > > > > its subscriber base should be of no concern to us. > > > >=20 > > >=20 > > > I am not so sure: technically yes, but not legally > > >=20 > > > At least in the current legal regime (PSTN) enterprises are below=20 > > > service providers and numbers are assigned from NRA to service=20 > > > providers, which in turn assign numbers to subscribers. SP=20 > > > interconnect with NNIs. > > > Enterprises are connected via UNIs. There are also differences in=20 > > > number portability. > > >=20 > > > Since regulations claim to be "technology" neutral, we have to be=20 > > > careful. > > >=20 > > > Richard > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 15:18:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI9Ws-0004WZ-3g; Fri, 16 Feb 2007 15:18:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI9Wq-0004To-Nk for speermint@ietf.org; Fri, 16 Feb 2007 15:18:00 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI9Wp-0003Bp-EM for speermint@ietf.org; Fri, 16 Feb 2007 15:18:00 -0500 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.729947; Fri, 16 Feb 2007 15:16:57 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 15:16:57 -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: [Speermint] Are we done?? Date: Fri, 16 Feb 2007 15:16:56 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BEBF@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Are we done?? Thread-Index: AcdPjcL403dQqbMzRoSioWCaoiWcOgCeYp9A References: <1171385264.17141.45.camel@montag.eng.level3.com> From: "Livingood, Jason" To: "Daryl Malas" , X-OriginalArrivalTime: 16 Feb 2007 20:16:57.0113 (UTC) FILETIME=[6847C090:01C75207] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dave and I have been doing a bunch of behind-the-scenes work to rework the milestones and to figure out how to move the group's work ahead. We should have an update soon... Jason=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Tuesday, February 13, 2007 11:48 AM > To: speermint@ietf.org > Subject: [Speermint] Are we done?? >=20 > After San Diego (or at San Diego), we talked a lot about=20 > identifying the basic, necessary concepts of establishing=20 > peering. We also talked about identifying the basic=20 > requirements for peering. I believe Jean-Francois was=20 > working on that. Since then, there have been no further=20 > discussions or updates to the drafts. I'm trying to=20 > determine what the most likely reason is for the silence. =20 > Either, we have already "beat the horse" and well defined the=20 > aspects I just mentioned, or we are too far off and we're=20 > unsure as to what direction to head next. ...Or, we are all=20 > to busy to work on this right now. I'm wondering if we=20 > should move these drafts to WGLC to determine if there are=20 > any new critical aspects to discuss. >=20 > Basic question...are we done with the initial drafts? >=20 > --Daryl >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 16:10:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAKu-0005BM-Kp; Fri, 16 Feb 2007 16:09:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAKs-0005As-UB for speermint@ietf.org; Fri, 16 Feb 2007 16:09:42 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAKf-0004o0-8R for speermint@ietf.org; Fri, 16 Feb 2007 16:09:42 -0500 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.735438; Fri, 16 Feb 2007 16:09:02 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:09:02 -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: [Speermint] Use cases and categorization Date: Fri, 16 Feb 2007 16:09:01 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BECD@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAKAl6wAGCe0YA= References: From: "Livingood, Jason" To: "Rodrig, Benny \(Benny\)" , "Uzelac, Adam" X-OriginalArrivalTime: 16 Feb 2007 21:09:02.0501 (UTC) FILETIME=[AF281D50:01C7520E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org That draft is available at http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us ecases-00.txt This will be reviewed in Prague. Assuming the WG finds the draft's cases worthwhile, we will seek to consolidate them into the draft Adam was discussing. You all may want to get a head start on looking at the draft and considering how to do this work. Thank you Jason=20 > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com]=20 > Sent: Wednesday, February 14, 2007 6:11 PM > To: Uzelac, Adam > Cc: speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Regarding question (2) - Enterprise peering cases should be=20 > addressed but I don't think they impact the categorization.=20 > John Elwell and I have a draft on enterprise use-cases to be=20 > submitted very shortly, and it is in line with the=20 > direct/indirect categories. >=20 > Benny=20 >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, February 14, 2007 1:14 PM > To: speermint@ietf.org > Subject: [Speermint] Use cases and categorization >=20 > Couple questions for folks... >=20 > We are working on a consolidation of use cases for SPEERMINT=20 > - and in that effort, we have acknowledged 3 categories of=20 > use cases: Direct, Indirect and Assisted. This falls inline=20 > with the terminology draft. > With that in mind... >=20 > 1) Per the definition of a 'Federation' in the terminology=20 > draft - "A federation is a group of SPs which agree to=20 > receive calls from each other via SIP, and who agree on a set=20 > of administrative rules for such calls (settlement,=20 > abuse-handling, ...) and the specific rules for the technical=20 > details of the interconnection." I read this to mean that=20 > any and all of the above peering categorizations involve the=20 > use of a Federation. Do we have consensus on that? >=20 > 2) Should we address any nuances between Enterprises and SPs=20 > as it pertains to the above categorizations? =20 >=20 > I appreciate any and all thoughts on the topics. >=20 > Adam Uzelac > Principal Network Eng./Sr. Manager Converged Arch. > Global Crossing > 585-255-8916 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 16:13:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAOE-0006Dr-FW; Fri, 16 Feb 2007 16:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAOD-0006DY-J3 for speermint@ietf.org; Fri, 16 Feb 2007 16:13:09 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAOB-0006Et-9k for speermint@ietf.org; Fri, 16 Feb 2007 16:13:09 -0500 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.30459549; Fri, 16 Feb 2007 16:12:46 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:12:45 -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: [Speermint] Use cases and categorization Date: Fri, 16 Feb 2007 16:12:45 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BED1@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAdyyggAEz6VRA= References: <1DDB0D3CC4E7F14FAE946361C0A606550221C8F2@isr-jlm-mail.Kayote.com> From: "Livingood, Jason" To: "David Schwartz" , "Uzelac, Adam" , X-OriginalArrivalTime: 16 Feb 2007 21:12:45.0830 (UTC) FILETIME=[34456A60:01C7520F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I hope you are not seriously suggesting yet another term "aggregator" for the terminology draft? I know we all like to be creative in our own ways with word-smithing, but can we stick with existing terms unless there's a major disconnect? ;-) Jason=20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 > Sent: Thursday, February 15, 2007 3:35 AM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Hi Adam >=20 > > Couple questions for folks... > > > > We are working on a consolidation of use cases for=20 > SPEERMINT - and in=20 > > that effort, we have acknowledged 3 categories of use=20 > cases: Direct,=20 > > Indirect and Assisted. This falls inline with the=20 > terminology draft. > > With that in mind... > > > > 1) Per the definition of a 'Federation' in the terminology=20 > draft - "A=20 > > federation is a group of SPs which agree to receive calls from each=20 > > other via SIP, and who agree on a set of administrative=20 > rules for such=20 > > calls (settlement, abuse-handling, ...) and the specific=20 > rules for the=20 > > technical details of the interconnection." I read this to mean that > any > > and all of the above peering categorizations involve the use of a=20 > > Federation. Do we have consensus on that? > > > > 2) Should we address any nuances between Enterprises and SPs as it=20 > > pertains to the above categorizations? >=20 > I have always preferred the term aggregator to service=20 > provider as the point to focus on is that peering involves=20 > interconnection between two (or more) parties that represent=20 > many more entities. With that in mind I see no reason to=20 > differentiate between SP's and enterprises (some of which are=20 > larger than many SP's) since both are performing the=20 > "aggregation" function. >=20 > IMHO, the relationship between the "aggregator" (SP or=20 > enterprise) and its subscriber base should be of no concern to us. >=20 > D. >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 16:16:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAR8-00077B-Td; Fri, 16 Feb 2007 16:16:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAR7-00076p-Aj for speermint@ietf.org; Fri, 16 Feb 2007 16:16:09 -0500 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAR5-0007Za-Vg for speermint@ietf.org; Fri, 16 Feb 2007 16:16:09 -0500 Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.30459729; Fri, 16 Feb 2007 16:15:43 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:15:43 -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: [Speermint] Use cases and categorization Date: Fri, 16 Feb 2007 16:15:42 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BED2@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use cases and categorization Thread-Index: AcdQY/bBIlrNQnD3SouDa9RsckEDIwAKAl6wAB3NspAABj49gAA8zNYg References: From: "Livingood, Jason" To: "Rodrig, Benny \(Benny\)" , "Uzelac, Adam" X-OriginalArrivalTime: 16 Feb 2007 21:15:43.0386 (UTC) FILETIME=[9E1A4FA0:01C7520F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think what I hope to see is that you two guys can "sit down together" (in the virtual sense) and see where there is overlap and where there are new use cases, that would end up dictating additional/special requirements... We'll hear a presentation on this draft in Prague but if you guys are able to do some work beforehand, that would be helpful. Heck, I'll even buy a round of beers for you. ;-) Jason=20 > -----Original Message----- > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com]=20 > Sent: Thursday, February 15, 2007 11:24 AM > To: Uzelac, Adam > Cc: speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Adam, >=20 > The enterprise peering use cases we have captured are=20 > actually similar to service-provider cases and don't show a=20 > major difference, but only potential differences in some=20 > details e.g. regulatory aspects and the possibility of using=20 > low-granularity number ranges for routing.=20 >=20 > Benny >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Thursday, February 15, 2007 8:17 AM > To: Rodrig, Benny (Benny) > Cc: speermint@ietf.org > Subject: RE: [Speermint] Use cases and categorization >=20 > Generally speaking, what are the differences between the use=20 > cases that you have captured versus the use cases that have=20 > already been captured? > At an interim Speermint meeting last summer (Philly) there=20 > was some rather lively discussions on this point, as well as=20 > in San Diego. =20 >=20 > Thanks in advance. >=20 > -AU=20 >=20 > > -----Original Message----- > > From: Rodrig, Benny (Benny) [mailto:brodrig@avaya.com] > > Sent: Wednesday, February 14, 2007 6:11 PM > > To: Uzelac, Adam > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Use cases and categorization > >=20 > > Regarding question (2) - Enterprise peering cases should be=20 > addressed=20 > > but I don't think they impact the categorization. > > John Elwell and I have a draft on enterprise use-cases to=20 > be submitted >=20 > > very shortly, and it is in line with the direct/indirect categories. > >=20 > > Benny > >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Wednesday, February 14, 2007 1:14 PM > > To: speermint@ietf.org > > Subject: [Speermint] Use cases and categorization > >=20 > > Couple questions for folks... > >=20 > > We are working on a consolidation of use cases for SPEERMINT > > - and in that effort, we have acknowledged 3 categories of=20 > use cases:=20 > > Direct, Indirect and Assisted. This falls inline with the=20 > terminology >=20 > > draft. > > With that in mind... > >=20 > > 1) Per the definition of a 'Federation' in the terminology=20 > draft - "A=20 > > federation is a group of SPs which agree to receive calls from each=20 > > other via SIP, and who agree on a set of administrative=20 > rules for such >=20 > > calls (settlement, abuse-handling, ...) and the specific=20 > rules for the >=20 > > technical details of the interconnection." I read this to=20 > mean that=20 > > any and all of the above peering categorizations involve=20 > the use of a=20 > > Federation. Do we have consensus on that? > >=20 > > 2) Should we address any nuances between Enterprises and SPs as it=20 > > pertains to the above categorizations? > >=20 > > I appreciate any and all thoughts on the topics. > >=20 > > Adam Uzelac > > Principal Network Eng./Sr. Manager Converged Arch. > > Global Crossing > > 585-255-8916 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 16 16:19:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIATb-0007hy-9S; Fri, 16 Feb 2007 16:18:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIATZ-0007ht-Ua for speermint@ietf.org; Fri, 16 Feb 2007 16:18:41 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIATY-0008E6-JW for speermint@ietf.org; Fri, 16 Feb 2007 16:18:41 -0500 Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.736355; Fri, 16 Feb 2007 16:18:28 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:18:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] draft-haluska-sipping-directory-assistance-02.txt Date: Fri, 16 Feb 2007 16:18:27 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BED3@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-haluska-sipping-directory-assistance-02.txt Thread-Index: AcdRcE9wOoS2ccvDSzeMFgaV4I0OrQAn2LvQ References: From: "Livingood, Jason" To: "Haluska, John J" , X-OriginalArrivalTime: 16 Feb 2007 21:18:28.0040 (UTC) FILETIME=[003E8480:01C75210] X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1751893503==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1751893503== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75210.0011CDDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75210.0011CDDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There may be some use cases to consider here. I suspect that, on some level, a DA provider looks like a service provider. A service provider sends a DA provider real-time calls, just like it would to another SP. So let's have you talk to the WG in Prague and see where we end up. You may want to take a look at the other use cases submitted within the WG and consider either adding a special use cases section to a -03 rev of your I-D or submitting a -00 on the subject. =20 =20 Jason ________________________________ From: Haluska, John J [mailto:jhaluska@telcordia.com]=20 Sent: Thursday, February 15, 2007 9:15 PM To: speermint@ietf.org Subject: [Speermint] draft-haluska-sipping-directory-assistance-02.txt =09 =09 Hello All, =09 =09 We are seeking comments on the latest revision of draft-haluska-sipping-directory-assistance-02.txt =09 This revision goes into much more discussion about applying specific SIP mechanisms for these kinds of services. =09 In addition to specific needs of providing Directory Assistance type services, this draft also discusses several inter provider scenarios which might be more generally applicable to other types of services which might be provided on a similar basis (e.g. by specialized service providers). I'm wondering if such scenarios might be interesting to the SPEERMINT working group. Also, we'd appreciate any comments on our approaches. =09 =09 Until it is available in the ID repository, it is available at =09 =09 ftp://ftp.research.telcordia.com/pub/world/haluska/draft-haluska-sipping -directory-assistance-02.txt =09 =09 Thanks much =09 John Haluska=20 ------_=_NextPart_001_01C75210.0011CDDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-haluska-sipping-directory-assistance-02.txt</TIT= LE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D397171621-16022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>There may be some use cases to consider = here.  I=20 suspect that, on some level, a DA provider looks like a service=20 provider.  A service provider sends a DA provider = real-time=20 calls, just like it would to another SP.  So let's have you talk to = the WG=20 in Prague and see where we end up.  You may want to take a look at = the=20 other use cases submitted within the WG and consider either adding a = special use=20 cases section to a -03 rev of your I-D or submitting a -00 on the = subject. =20 </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D397171621-16022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D397171621-16022007><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Jason</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Haluska, John J=20 [mailto:jhaluska@telcordia.com] <BR><B>Sent:</B> Thursday, February = 15, 2007=20 9:15 PM<BR><B>To:</B> speermint@ietf.org<BR><B>Subject:</B> = [Speermint]=20 draft-haluska-sipping-directory-assistance-02.txt<BR></FONT><BR></DIV> <DIV></DIV><!-- Converted from text/plain format --> <P><FONT size=3D2>Hello All,<BR><BR><BR>We are seeking comments on the = latest=20 revision of = draft-haluska-sipping-directory-assistance-02.txt<BR><BR>This=20 revision goes into much more discussion about applying specific SIP = mechanisms=20 for these kinds of services.<BR><BR>In addition to specific needs of = providing=20 Directory Assistance type services, this draft also discusses several = inter=20 provider scenarios which might be more generally applicable to other = types of=20 services which might be provided on a similar basis (e.g. by = specialized=20 service providers). I'm wondering if such scenarios might be = interesting to=20 the SPEERMINT working group. Also, we'd appreciate any comments on our = approaches.<BR><BR><BR>Until it is available in the ID repository, it = is=20 available at<BR><BR><A=20 = href=3D"ftp://ftp.research.telcordia.com/pub/world/haluska/draft-haluska-= sipping-directory-assistance-02.txt">ftp://ftp.research.telcordia.com/pub= /world/haluska/draft-haluska-sipping-directory-assistance-02.txt</A><BR><= BR><BR>Thanks=20 much<BR><BR>John Haluska</FONT> </P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C75210.0011CDDE-- --===============1751893503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1751893503==-- From speermint-bounces@ietf.org Fri Feb 16 16:44:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAsh-0003jM-Ul; Fri, 16 Feb 2007 16:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIArf-0001AZ-3j for speermint@ietf.org; Fri, 16 Feb 2007 16:43:35 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIArd-0004M5-GZ for speermint@ietf.org; Fri, 16 Feb 2007 16:43:35 -0500 Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.738613; Fri, 16 Feb 2007 16:43:05 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:43:05 -0500 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_01C75213.70BD4C5E" Date: Fri, 16 Feb 2007 16:43:05 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Updating Milestones Thread-Index: AcdSE3DBUmRuLJQtT966R6MccCTkrw== From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> To: <speermint@ietf.org> X-OriginalArrivalTime: 16 Feb 2007 21:43:05.0616 (UTC) FILETIME=[70F2B900:01C75213] X-Spam-Score: 0.0 (/) X-Scan-Signature: aa2b6865388ed2f1295c7d4bf9c7d520 X-Mailman-Approved-At: Fri, 16 Feb 2007 16:44:38 -0500 Subject: [Speermint] [wg-business] Updating Milestones X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C75213.70BD4C5E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All -=20 We have been spending a lot of time thinking about our current milestones and, philosophically, about how documents and work flows through the group. I am a bit of a visual thinker so I created the 3 variations of document flows to facilitate discussion with our ADs and other stakeholders. Those different flows are attached, for your information. I believe we have concluded this now and we are close to an update of our milestones (see below). In addition, if you open those flow charts, we have concluded that Document Flow v1-C will satisfy the various interested parties in SPEERMINT and will be using that as a guide. A few key points: * This recognizes that VoIP (TN-based URIs and voice apps) and IM (username-based URIs and various apps) have very different use cases and requirements. Continuing to try to jam them together is counter-productive. Separating them will accelerate each track of work. * This recognizes that it is not for us to decide if TN or name-based URIs win/lose in the end. We work to accomodate applications that use both; the market and implementers will ultimately decide upon success or failure. * Many of the pieces of the infrastructure used converge in the architecture document, though there will be important differences in some cases. There is enough similarity and potential for shared elements that one overall architecture seems to hold some promise. * Out of that flows application / implementation-specific docs, on message flows, DNS/NAPTR, etc. These should very specifically tell an implementer what they need to do. * There are 3 likely stages or levels of deployment that should be accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open Internet). Depending upon the implementer, the maturity of their app/business/users/regulations/etc., one may make sense. In general, the lifecycle is Direct --> Federated --> Open. It is impossible for us to predict or guide when the market or implementers will go to each stage; we should try to describe how to do each and let implementers figure out the rest. This also recognizes that this is not a battle of direct vs. federated vs. open, as each has a place and a role. --> CURRENT Goals and Milestones: Jul 2006 Submit SPEERMINT terminology I-D (Informational) Sep 2006 Submit I-D defining the SPEERMINT routing architecture (Informational)=20 Dec 2006 Submit I-D defining the message flows associated with the SPEERMINT routing architecture (Informational)=20 Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP)=20 Mar 2007 Submit I-D on the minimum set of requirements for SIP-based VoIP interconnection (BCP)=20 Jul 2007 Submit I-D specifying the use of strong identities in session peering and supporting the establishment and exchange of trust between domains (BCP)=20 Jul 2007 Submit I-D(s) on use cases (BCP)=20 Jul 2007 Propose re-chartering for any additional efforts/considerations, or propose conclusion of working group (following approval of last documents)=20 --> PROPOSED New Goals and Milestones: Apr 2007 Submit SPEERMINT terminology I-D (Informational) Aug 2007 Submit SPEERMINT VoIP-specific use cases I-D (Informational) Aug 2007 Submit SPEERMINT IM-specific use cases I-D (Informational) Jan 2008 Submit SPEERMINT architecture I-D (Informational) Feb 2008 Submit SPEERMINT message flows I-D (Informational) Feb 2008 Submit SPEERMINT DNS SRV and NAPTR use I-D (BCP) Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP interconnection. (BCP) Mar 2008 Propose re-chartering for any additional efforts/considerations, or propose conclusion of working group (following approval of last documents) Regards Jason ------_=_NextPart_001_01C75213.70BD4C5E Content-Type: image/jpeg; name="SPEERMINT Document Flow - v1-C.jpg" Content-Transfer-Encoding: base64 Content-Description: SPEERMINT Document Flow - v1-C.jpg Content-Disposition: attachment; filename="SPEERMINT Document Flow - v1-C.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAIjAkMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOWufHmm2+j6fqUdlqN0t/cyWsEFtAHlZ 0L7vl3dP3bd6daeM/tcd0/8AwjXiOH7PEZds1htMnIG1Pm5bnOPQGuDiDnwx4IEeoDT3/ty9xdFV YR/8fXOG49ufWvQdAFwt7IJ/FsesAxnECxQqVOR83yc+340AZcPxKtri+ls4/DPic3EIQyp/Z/MY bO0t83AOD+VTSfEO1+3Xtta6B4gvfsdw9tLLaWQkj3qcEA7v85qbRf8Ako3iv/r3sP8A0GWuf8K6 XrF7d+J5bDxFLp0I166UwpaRSAnK/NlgT6ce1AHocF0k1hHduj26PEJWWcbGjBGcMOxHf0rm4vH+ nSGCaTT9Wt9OuGVYtRmtdtu244Q5zuVSSMFgByK6HUHSHSbqSaCS6jSBy8UagvKApyoHGSemOOte XTahDofhODUNA8UxalpSpGIdD1JYpncEqBCrD5ww6AHdgigDsdR8d2thrd5pMWi63f3FoEMzWNoJ VXeu5ed3p7djSXPxB0mHTbW8gttRvGuLtrIWtvbEzpMqlmRkYgggKc1j2NtrFx8SvGP9l6la2YAs t/nWZnLHyTjGJFx39aoa7oEmgP4biOuMl7d67Nd3GpSRIAJGt5ckIflAwAAOaAOv07xel/8AajJo WuWKW0DTtJe2flKwXqqndy3t7Gs61+I0N7BBPb+FvFDwzqrxyjTvlZWGQc7umDmnoLhdM1YT+LY9 YBsZcQLFCpU7fvfJz7fjWN4UF2nhjRGPj6KGMWcB+zNBbfINi/ISRnjpnrQB0l540gt9bvdJt9H1 e+uLIRmdrSBGVd67l5Ljt7dqhufiJolp4ZvNdmS9WGynW2urZoCs8MhKgKUOP7yng4weK58abr1/ 8RfGJ0PX10p0Wz3BrNJxIxhO3O7oBg9PWsgLBL4Juzd+a2uSeIbJdZS5KMwmE8SgAKAPLKgFeOQf rQB6ZrHiTTtE8Nya9cO8lisaSKYV3M4YgLtHGc5FV4fF+mzzRxIlxufShqwyg/1JOMdfve3T3rz2 +3XWi3vhObcy+G7e9mm3kksixkWn5pJn6xVZ07/kJ2n/AGIif+hCgDutO8YaTqvg9/E9nI8unpBJ O4CjzFCAllIzwwweM1m6t8Q7PR082fQ9eltSkTi6hsw0R8wLtG7d1ywH14rh7+OTwn8N01a2jkfS dY0FIL+KNciC4a32xzgejEhG/wCAmuu8V/8AJKLf/dsP/R0NAHT6HrP9t2sk/wDZmo2Gx9nl38Hl O3AOQMnI56+1YTfEKz+33lrBoev3S2dw9tNcW1l5kYdT83IbP6ZrsK4HwbrGmab/AMJT9v1G0tca /dMfPnVOPl55NAHST+K9Fg8OJrxvQ+nyAeU6KS0rE4CKuNxYnjbjOaqWXjWyuNSt7C90/U9KmuiV tjqFv5azMBnarAkbsc7Tg+1cNZ/6Fpul+I7lWTQP+Elur4KUKiGCUOkUzDsoY7snoHzXT+NtTsNU tNL0jT7qC51S71C2ltBA4dogkiu03y5wqoG56c470Aal/wCMrS01K4sLTTtT1S4tsC5Gn2+9YSRk BmJAzjnAJPPSpYfF+k3On6Ze28kssOo3Ys4sJhklwxKupwVI2MCOuaxPBmpWOlTeIdM1G8gt9Qi1 a5uJVnZY2kjkbekgBPKlSBn/AGapaxremX+laHrdlbm20uHxGry3LIqRyLiRDPkfwMzD5jjPX3oA 7e81e2sdU03T5VkM2oPIkJUAqCiFznnjgGqXhnxXpviu2u5tO80C0uGtpVlUKwZe+ATx6H2NY+ra hZ6l4+8JQ2NzDdPC11PL5Dh/LTySoZsdAWYAetcZol/L4W0m31C0UmTWoruyiVUyGvUuZfIz9Q7j 6JQB3DfEfRfsOq3cUN9Mmm3iWUixRAtLI7BV8sbvmBJHPFW9J8X/ANq6jFZ/8I74gs/Mz+/vLLy4 lwCeW3HGcYHua861TTItHsPEWm20/kJbaposSzkD5SBAN5B4znk5r0HRxdLqcXneNotTTn/RRDAp fg90546/hQBe8N+KdL8VWtzPpsrH7NcPbzRyAB0dTjkZPB6g/wD16yLn4jWNvpNvqqaLrlzYzWxu jPb2gdY0BYHed2ARtJ+mK5XQIZfD3hqy8YWMUkiRS3UWq28S5M1v9pk/eAd3j6+67hWporB/2fXZ TkHRLgj/AL4egDq/D3iZPESyPHpOq2Uaqrq99beUsgbONpyc9P1FUdR8d2thrd5pMWi63f3FoEMz WNoJVXeu5ed3p7djW3of/Iv6b/16xf8AoAribTT9UvviV4vOna3JpoT7FvCW0cvmZhOPvg4xz09a AOqtPE1tcz6VbyWd9a3GpJM8UNzCEdBERu3jPGdwI65q5rOtWOgaa9/qE3lwqQoAUszsThVVRyzE 8ACuZ1eRdP8AG3g/+0L5GZLW9WS4m2xh22xckcAZ9BR4wv7RZ/DutNcRz6Rp+pZvHibekRaJ0SRi MgBWZc56bs0AaFl41srjUrewvdP1PSprolbY6hb+WszAZ2qwJG7HO04PtVhvFump4cvtbdZxb2Uk sU0Xl/vRJG5QqFzySw455yKxfG2p2GqWml6Rp91Bc6pd6hbS2ggcO0QSRXab5c4VUDc9Ocd6ybmN ovH8/hZflg1DUoNaK4BBiRCXB9jNAn/fdAHZHxVp39kaTqS+a8Oqyww2yqoLFpOmRnjAyT6YNXdW 1ez0Swa8vpCkYYIqqpZ5HJwqqo5ZiegFcD4fhdvG8XhxsLB4eubu8VByNkwUwA/RZpR/wCt3xw62 d54b1S6P/EtstSDXRP3Y90bokjegVmHJ6bs0AXdO8YWt7qkOnXOnanplzcBjbrf24QT7RlgpBIyB zg4OO1aejavba7pceoWiyCF3kQCQANlHZD0J7qaoXfiLRZNW0uwjaHULy5kLwrAUkMKhTmYnPyqM 4z1O7AzXM+BtH1S58JwzW/ia+tImuLrbBHb27Kn+kSdC0ZPvye9AHUJ4r01/CH/CTHzksDCZgGUb yM4AxnqTwBnuKd/wlOnf8Ie3ihTK2nram6IC/OFAyRjP3hgjGeorzjSZb7UPCfgjQNNghu5FjGpX kM03lBoYnwgY7W4aQqenOw0/UJ77TfCvj3w/qdvDayPZXGp2cMUxlVYZAQ6htq8CTJ6D79AHZP4+ tLZI5tR0bW9PtHZVN3c2o8pCxAUsVY7QSRyRio9W+Idro18bW50DxAc3H2aKVLIGOZyTgISw3Zxx 61zXiHTdZstO0/8A4SbxDLqXheeSJL9IbOOBoRlTGWIBJj3BQ2CCAa6Tx+QR4WIOQfEFp/7NQB0O j6p/bFgLv7BfWWWK+Tew+VJx325PFaFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFGbRdKubRLSfTLKW2jYukMkCsisc5IUjAPJ59z TbLQtH02cz2GlWNrMV2mSC3RGx6ZA6cVoUUARpbwRzyTpDGs0oAkkVQGcDpk98ZOPrSQ20Ft5nkQ Rxea5kk2IF3uerHHUn1qWigArPTQdGiv/t8ek2CXuS32hbZBJk9TuxmtCigCJLaCKeWeOCNJpseb IqAM+Bgbj1OB0zUV9pthqcSxX9lbXcatuVLiJZAD6gEdatUUAZ1r4f0Wxd3tNH0+3d0MbNFbIhZT 1BwOQfSoB4T8Ng5Hh/Ss/wDXlH/hWxRQBEltBFPLPHBGk02PNkVAGfAwNx6nA6ZqJ9NsJJpZXsrZ pZWRpHaJSXKcoSccle3p2q1RQBAbG0ZrhjawFrlQk5MYzKoGAG/vDBI59aaNOslYMtnbgiH7OCIl 4i/udPu+3SrNFAEDWVq9l9ia2ha02eX5BjBTbjG3b0xjtSyWltNbC2lt4ntxtAiZAV4II46cEDH0 qaigArMk8N6FNdNdS6Lpz3DPvaVrVC5brknGc+9adFACOiyIyOoZWGCpGQR6VSsNE0rSnd9O0yys 2k4dre3WMt9doGavUUAUb/RNK1V0fUdMsrxo+Ea4t1kK/TcDirTW8L25t3hjaArsMRUFSvTGOmPa pKKAKWn6Ppmkhxpum2dkJMbxbQLHu+u0DNSDTrFYoYhZ24jhk82JBEuI3yTuUY4OSeR6mrNFAFS4 0vTrtJ0uLC1mW4KmYSQqwkK/dLZHOMDGemKr23hzQ7K5S4tNG06CdOUlitUVl7cEDIrTooAihtbe 3t/s8MEUcPP7tEAXkkngcckn86aljaR2P2KO1gS02FPIWMCPaeo29Me1T0UANREjjVEUKigBVUYA A7CmJbQRTyzxwRpNNjzZFQBnwMDcepwOmalooAp3+k6bqgjGoafaXYjzs+0QrJtz1xkHHQflTrTT LCwtXtbOxtre3cktFDEqIxIwcgDB4q1RQBRsNE0rSnd9O0yys2k4dre3WMt9doGasm1tzdi7MERu VQxibYN4UnJXd1xnnFS0UARJbW8dzJcpBEs8oCyShAGcDoCepxk4+tPkjSWNo5EV0YFWVhkEHqCK dRQBRsNG0vSi507TbOzMn3zbwLHu+u0DNWoLeC1hENvDHDECSEjUKoJOTwPUkn8akooArW2m2Nm4 e1sreBxGIg0USqQgJIXgdMknHvRcafZXjl7mzt52MbRFpYlY7G6ryOh7irNFAEU1tBcW7288McsD rtaJ1DKw9CDwRTXsrWSOGN7aFkgZXiVowRGy/dKjsR2x0qeigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8 /svGHi3VxdT6Z4f0trSK6mt0afUHR28uQoSQIzjO31q1/bfj3/oXdE/8Gj//ABqoPh9/yALz/sK3 3/pQ9dXVqKJbOb/tvx7/ANC7on/g0f8A+NUf2349/wChd0T/AMGj/wDxqukop8qC7Ob/ALb8e/8A Qu6J/wCDR/8A41R/bfj3/oXdE/8ABo//AMarpKKOVBdnN/2349/6F3RP/Bo//wAao/tvx7/0Luif +DR//jVdJRRyoLs5v+2/Hv8A0Luif+DR/wD41R/bfj3/AKF3RP8AwaP/APGq6SijlQXZzf8Abfj3 /oXdE/8ABo//AMao/tvx7/0Luif+DR//AI1XSUUcqC7Ob/tvx7/0Luif+DR//jVH9t+Pf+hd0T/w aP8A/Gq6SijlQXZzf9t+Pf8AoXdE/wDBo/8A8ao/tvx7/wBC7on/AINH/wDjVdJRRyoLs5v+2/Hv /Qu6J/4NH/8AjVH9t+Pf+hd0T/waP/8AGq6SijlQXZzf9t+Pf+hd0T/waP8A/GqP7b8e/wDQu6J/ 4NH/APjVdJRRyoLs5v8Atvx7/wBC7on/AINH/wDjVH9t+Pf+hd0T/wAGj/8Axqukoo5UF2c3/bfj 3/oXdE/8Gj//ABqj+2/Hv/Qu6J/4NH/+NV0lFHKguyl4P1+48R6LJd3dpHa3MV1NayRRyGRQ0blS QSBkcelb9cb8Nf8AkA6l/wBhm+/9HtXZVmUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAcF8Pv+QBef9hW+/8ASh66uuU+H3/IAvP+wrff+lD11darYhhRRRQIKKKKACiiuZ1W /wBdt/E2n6baXenJBfLMyGWyd2j8sKcEiUBs7vQY96BnTUVx+h+JbzVdQEUmpafGftM0X2RbCXft jd1H7zzNuSFznb36VQ0PxrqGpJpjefY3c11H5lxa29nLG1smxm3l2cgqGAXoM7uOeKLgd/RXBweO b6TwppV61rb/ANp3V5FbzxAMEjRmUlwM5xsdCOerrVm28ZXY1O1W7t4BYSecs8yZBhIuGiRjk42n aAfQtnoDRcLHZ0Vydhr+ra1cfY7L7FbyxiWSeaaJpFCieSKNVQOpJPlMSd3GOnPFjRPEN3qOsSaf cwQxyW8LifyySDIsmzKk/wAJGDgjIzjPFFwOkormm1bWb46ldaWLEWtjM8KwzxuZLh4/v/OGAjGc qPlbpnviqa+LLjUrK41OwvtKsNPgZI1bUgR50jRrJjdvURj5wvRjkE49S4HY0VysniW/WcWSW9vL d36JLpUkZLQuhUbi7A8+X94kEblK45NdSM7RuIJ7kDFAC0UUUCCiiigAooooA5/4a/8AIB1L/sM3 3/o9q7KuN+Gv/IB1L/sM33/o9q7KsjQKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooA4L4ff8gC8/wCwrff+lD11dcp8Pv8AkAXn/YVvv/Sh66utVsQwooooEFFFFABVK50uC61a x1F2kE1msixhSNpDgA54/wBkYq7RQBiWHh6TTZALbWtRW2895vsxWAoS7l2GfK3YJY/xZ96I/C9l FYaVaxy3C/2YvlwTBl3lNu1lbjBDDGeOwIwQK26KBnOp4L0tAgV7kbIIIR846RMjBun3j5cYY9wg xirNr4Z0+1eQ/vJUkhlheOUgqyySNIwIx6sR9K2aKAOdtPCFtp0Fsmn6hfWssCPH56sjvIjOXKvv Ug4ZiQcZGTzycrH4Sitpo57HVNQs5gjJJJH5TtMWcuzPvjb5ixJ4x6dK6GiiwGFP4Xjm+0omp38E F5zdQxNGFmJXaxyUypYAZ2FfXg80svhmISzNYaheadFcKomhtfL2PhQoIDo207QoyuOAO/NblFAG dBolnay6a8AdF062a2gTdkBCEHOeSR5a9/WtGiigQUUUUAFFFFABRRRQBz/w1/5AOpf9hm+/9HtX ZVxvw1/5AOpf9hm+/wDR7V2VZGgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQBwXw+/5AF5/wBhW+/9KHrq643TfDnjjQ0urXTpvD0lrJeT3EZuPO34kkZ8HHHG6rv2X4i/3vC3 /kxVqSJaOlormvsvxF/veFv/ACYo+y/EX+94W/8AJinzIVmdLRXNfZfiL/e8Lf8AkxR9l+Iv97wt /wCTFHMgszpaK5r7L8Rf73hb/wAmKPsvxF/veFv/ACYo5kFmdLRXNfZfiL/e8Lf+TFH2X4i/3vC3 /kxRzILM6Wiua+y/EX+94W/8mKPsvxF/veFv/JijmQWZ0tFcVo+peNfEFo93po0FYUkMbC6Ewbdg HjaSMYYe9aH2X4i/3vC3/kxVTXJJxfQUXzK6OlormvsvxF/veFv/ACYo+y/EX+94W/8AJip5kOzO lormvsvxF/veFv8AyYo+y/EX+94W/wDJijmQWZ0tFc19l+Iv97wt/wCTFH2X4i/3vC3/AJMUcyCz OlormvsvxF/veFv/ACYo+y/EX+94W/8AJijmQWZ0tFc19l+Iv97wt/5MUfZfiL/e8Lf+TFHMgsyX 4a/8gHUv+wzff+j2rsq53wVod94f0OW21KW3ku5rye6kNtu2AyOXwN3PGa6KsywooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDivhh/ yLVz/wBfjf8AoCV2tcV8MP8AkWrn/r8b/wBASu1rfFfxpGVD+GgooorA1CiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiikdtqMwUtgZwOpoA5fxfrep6ZcaXZ6WIfPvpGQNIM 4I2gD/x6qf8AxcD/AKh/6VheIvF+m6lreiXUKXCpYzl5g6AHGUPAz1+U13+ia5a6/avc2kcyxI+z dKoXJ9uTXbKMqVOLcF53XmcyaqTa5jnf+Lgf9Q/9KP8Ai4H/AFD/ANK7Wisfb/3V9xp7L+8/vOK/ 4uB/1D/0o/4uB/1D/wBK7Wij2/8AdX3B7L+8/vOK/wCLgf8AUP8A0o/4uB/1D/0rtaKPb/3V9wey /vP7ziv+Lgf9Q/8ASj/i4H/UP/Su1oo9v/dX3B7L+8/vOK/4uB/1D/0o/wCLgf8AUP8A0rtaKPb/ AN1fcHsv7z+84r/i4H/UP/Sj/i4H/UP/AErtaKPb/wB1fcHsv7z+84r/AIuB/wBQ/wDSj/i4H/UP /Su1oo9v/dX3B7L+8/vOK/4uB/1D/wBKP+Lgf9Q/9K7Wij2/91fcHsv7z+84r/i4H/UP/Sj/AIuB /wBQ/wDSu1oo9v8A3V9wey/vP7zznRdG8aaHZvbWSWaxtIZCHYMc4A/oK0f+Lgf9Q/8ASu1oqpYl yd3FfcJUUlZNnFf8XA/6h/6Uf8XA/wCof+ldrRU+3/ur7h+y/vP7ziv+Lgf9Q/8ASj/i4H/UP/Su 1oo9v/dX3B7L+8/vOK/4uB/1D/0o/wCLgf8AUP8A0rtaKPb/AN1fcHsv7z+84r/i4H/UP/Sj/i4H /UP/AErtaKPb/wB1fcHsv7z+84r/AIuB/wBQ/wDSj/i4H/UP/Su1oo9v/dX3B7L+8/vOK/4uB/1D /wBKP+Lgf9Q/9K7Wij2/91fcHsv7z+84r/i4H/UP/Sj/AIuB/wBQ/wDSu1oo9v8A3V9wey/vP7zi v+Lgf9Q/9KP+Lgf9Q/8ASu1oo9v/AHV9wey/vP7ziv8Ai4H/AFD/ANKP+Lgf9Q/9K7Wij2/91fcH sv7z+84r/i4H/UP/AErS8Ga3ea5pU8t8I/OhnaLMYwCAAf61F411TV9FsYb7Tmj8kNsmDpuxnof6 fiK4fwXq+sf2lHpdg8ax3ExlmZo87Rgbj+Q/OulU3VouVkv61MXPkqKN2z2CiiivPOsKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK4jx+txdar4X02LUL+ygvL6VJ2srloHYLA7A blIOMgVF/wAILD/0Mnin/wAHU/8AjTSuJs7yiuD/AOEFh/6GTxT/AODqf/Gj/hBYf+hk8U/+Dqf/ ABp8rC53lFcH/wAILD/0Mnin/wAHU/8AjR/wgsP/AEMnin/wdT/40crC53lFcH/wgsP/AEMnin/w dT/40f8ACCw/9DJ4p/8AB1P/AI0crC53lFcH/wAILD/0Mnin/wAHU/8AjR/wgsP/AEMnin/wdT/4 0crC53lFcH/wgsP/AEMnin/wdT/40f8ACCw/9DJ4p/8AB1P/AI0crC5geN/DcsHieJrOLKai+UA6 CQn5h+ufx9q9O0jTYtI0q3sYfuxJgn+8e5/E5Nca/gC1kaNpPEHidmjO5C2sTEqcYyOeDgkfjT/+ EFh/6GTxT/4Op/8AGt6tadSEYPoZQpxhJyXU7yiuD/4QWH/oZPFP/g6n/wAaP+EFh/6GTxT/AODq f/GsOVmtzvKK4P8A4QWH/oZPFP8A4Op/8aP+EFh/6GTxT/4Op/8AGjlYXO8org/+EFh/6GTxT/4O p/8AGj/hBYf+hk8U/wDg6n/xo5WFzvKK4P8A4QWH/oZPFP8A4Op/8aP+EFh/6GTxT/4Op/8AGjlY XO8org/+EFh/6GTxT/4Op/8AGj/hBYf+hk8U/wDg6n/xo5WFzvKK8vvdKn8OeKvCrWmva9Ol3qJg miu9SlmjdPKc4KscdQK9QpNWGFFFFIAooooAKKKKACiiigAooooAKKKKACiiigArjrz4reB7C9ns 7nxBAk8EjRyJ5ch2sDgjIXHWuxrz/wCHX/ID1H/sL3v/AKOamlcTdix/wuDwD/0McH/fqT/4mj/h cHgH/oY4P+/Un/xNdNRVcouY5n/hcHgH/oY4P+/Un/xNH/C4PAP/AEMcH/fqT/4mumoo5Q5jmf8A hcHgH/oY4P8Av1J/8TR/wuDwD/0McH/fqT/4mumoo5Q5jmf+FweAf+hjg/79Sf8AxNH/AAuDwD/0 McH/AH6k/wDia6aijlDmOZ/4XB4B/wChjg/79Sf/ABNH/C4PAP8A0McH/fqT/wCJrpqKOUOY5G/+ Knw71Gwns5/EUBimQo37mTjPf7vWuY8EeN/A2grdz3niG2+1SOY0IikP7sHr93uefwFeq0VcZSjB wT0ZLinJSe6OZ/4XB4B/6GOD/v1J/wDE0f8AC4PAP/Qxwf8AfqT/AOJrpqKjlK5jmf8AhcHgH/oY 4P8Av1J/8TR/wuDwD/0McH/fqT/4mumoo5Q5jmf+FweAf+hjg/79Sf8AxNH/AAuDwD/0McH/AH6k /wDia6aijlDmOZ/4XB4B/wChjg/79Sf/ABNH/C4PAP8A0McH/fqT/wCJrpqKOUOY5n/hcHgH/oY4 P+/Un/xNH/C4PAP/AEMcH/fqT/4mumoo5Q5jmf8AhcHgH/oY4P8Av1J/8TXT6JrumeI9NXUdIu0u rRmKiRAQMjqMEA0lc/8ADj/kG65/2Hr/AP8ARxpNWGnc7KiiipGFFFFABRRRQAUUUUAcX4z/AORr 8Ff9hCf/ANJpK6Kud8Z/8jX4K/7CE/8A6TSV0VXHYmQUUUVRIUUUUAFFFUNbe9i0a5m07m6hUSom AfM2kMU/4EAVz2zxQMv0Vx+oeIry5vo10q4C2kz29ok/lhlEko8wvz/djCbexMvIOMUzVNU1TQ7t rD+0nvPMWCaOaaOMSRg3EcbqwVQpBD8HAIw3XjBcDs6K4DStc1e5ljmW71GZhqE0dwk1kiWiW6Su rES7F5CAH7xyRjFaeqaxcX0tvPo19cTaaI282TSlhmlV8gDcrg5TAb7ozmi4HWUV563iHULu+ljh 1XUpNum280R03ThJG8r+YGLho2KjKD5Sy45zU2maprd9ql1Df3OrwSxXMcLRWFtA9vGTFEzAsyM3 DM3OemKLgd5RXMWlxqeoW82rHV/scUd5LEttJFGIRHHKYzvJG/cdhOQwAJHHHOOdd1W5ubCI3mpK si3rP/Z1tC7kx3IjTIdGAAU4474ouB39Fcb/AGtqb6k2kx3cqmW/itVuZIk8yNBaCZjgDbvYqeow Nx4wMV0WmJcwPcW1zqQvmRgUZ1RZVUjo4QAdQcEAcUAaFFFFAgooooAKKKKAOT8W/wDIy+C/+wuf /RMld9XA+Lf+Rl8F/wDYXP8A6JkrvqiW5a2CiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFef /Dr/AJAeo/8AYXvf/RzV6BXn/wAOv+QHqP8A2F73/wBHNVR3EzrqKKKsgKKKKACiiigAqub6zWdY DdQCVnMaxmQbiwG4qB64IOPSrFecatpN/caxcT29pMZrfUpry3byzhmS3gKjPoxUr+JoGehrPE80 kKyo0sYBdAwLKDnGR2zg/lUQ1GyN+bAXlubwLuNv5q+YB67c5xXJaJHqy6/qmqW9gjSalBbTMt3K 0ARN84UcI3ziMRZXjBJyar+UItaWO2gllLar5z2d3YMHjJl+aaOdcDaASw3bsj5eOlFwOwt9a0q7 SR7bU7OZYlLSGOdWCAdScHgCiz1rStRlaOx1OyuZFXcywTq5C+pAPTkVwVr4a1Gb4fWk100AktNL lMNtFYMk+5rd02Oxck/e6BRkgelOga7vvDEliszXLi2hMltHo81u5jV0Mqb2OHJQMu3vmlcDvoNV 065ieWC/tZY0cIzxzKwVicAEg8EkgYqL+3dI+2Gz/tWx+1Bihg+0JvDDqNuc59q5nVmsdRiZtJ0u 4Lq1qr3C2zxrhbmM7MEDcQAxPHygHpmp9E0zUk/tKd5YVtmvbxlt2sz5rAyPgiTd0OQR8vSmB0k+ qafbRQSz39rFHcY8l5JlUSZ6bSTz+FW68+0FYdKjD65ZTSCbS7OO3Bs3lwqxYeLAU4bdklTjO7vj jt9MULpNmq2z2yiBAIJG3NENo+UnnJHT8KALVFFFAgooooAKKKKACuf+HH/IN1z/ALD1/wD+jjXQ Vz/w4/5Buuf9h6//APRxqZFROyoooqCgooooAKKKKACiiigDi/Gf/I1+Cv8AsIT/APpNJXRVzvjP /ka/BX/YQn/9JpK6KrjsTIKKKKokKKKKACiiigDIfRNE0/QZ7N7eOHTV3TyBnICYO4vuzkYxkEHj AxjAqI6ToNoskczgtcKs7Pc3bu7LCwcHe7E7VJB64Gfc1b8QWcuo+G9UsYADNc2ksMYJwNzIQP1N cxfrJrrRBNHv5YbfS7mG4hnja3LtJ5Y8tGYcthG5GV6c80DNzT9X8N2elTyWOpWYsbeQvM63AZUa RyckknG5mOPrxSBdB8Uy/aLW98+W3GxprG7eJ1VudrNGwJBx0P4VymqRand6feeQupXcSrakXNzp wjuoytzG2xQEHmAKGY/KRkdTmus0C4muYLlXvNTmcEYe/sRblcg/dGxd3Tnr2pAGmSeG7TVZbPTr mzW+8tIHgjnBfbHuwu3PUbmz355pj6ToUt7qF0t1cRTJIJLzyNTmiVX2Ly6q4UfKF7dBWZpl2+m6 DpWmS+H7u4vbCMecPsx2IyIQ0qPja7Mc4Cncd/OOazl0PVrG3ke7sUv11a0liv7e2zG5kbfKCW5H G6RAeBygoA2W/wCEPuxc6p9vt3t4pkluQl63keYSArPGG2EkgckckdzU9jqHhOCNtQtNQsVjtg8b TfaflTzX3sDk4yzDP4cVzWqRand6feeQupXcSrakXNzpwjuoytzG2xQEHmAKGY/KRkdTmtN3ku7K J5pfEFybe7SQXLWIhmtso670Tyh5g5KkbW4bOKAN5LDRNatZbmDy7mK6lWZp4JjzIgChlZTlWAUD gjp9atadpVppaSLbJJulbfLJLK0kkhxjLMxJPAA68dqo+GBcizumuYyN9yzRzPbeRJcLtX55E4w2 cjoMhQcDNbdMAooooEFFFFABRRRQByfi3/kZfBf/AGFz/wCiZK76uB8W/wDIy+C/+wuf/RMld9US 3LWwVXvb+z06Dz767gtYc7fMnkCLn0yT1qxXO+JY0l1nwokiK6nVXyrDIP8AoV1UjLX/AAlnhv8A 6GDSv/A2P/Gj/hLPDf8A0MGlf+Bsf+NaH2Cz/wCfSD/v2KPsFn/z6Qf9+xQBn/8ACWeG/wDoYNK/ 8DY/8aP+Es8N/wDQwaV/4Gx/41ofYLP/AJ9IP+/Yo+wWf/PpB/37FAGf/wAJZ4b/AOhg0r/wNj/x o/4Szw3/ANDBpX/gbH/jWh9gs/8An0g/79ij7BZ/8+kH/fsUAZ//AAlnhv8A6GDSv/A2P/Gj/hLP Df8A0MGlf+Bsf+NaH2Cz/wCfSD/v2KPsFn/z6Qf9+xQBn/8ACWeG/wDoYNK/8DY/8aP+Es8N/wDQ waV/4Gx/41ofYLP/AJ9IP+/Yo+wWf/PpB/37FAGf/wAJZ4b/AOhg0r/wNj/xqa08QaLf3C29nrGn 3E7Z2xw3KOxxycAHNWvsFn/z6Qf9+xWFr9tbw6v4YaKCJG/tUjKoAf8Aj2uKAOlrz/4df8gPUf8A sL3v/o5q9Arz/wCHX/ID1H/sL3v/AKOaqjuJnXUUUVZAUUUUAFFFFABWaNWz4mfRvJ5WzW683d6u V24x7ZzmtKsfUNJu5NWTVNNu7e3uvI+zSfaLcyqybtwwA6kEHPcjn8aBmSPGkszWsVvY2onngMyx 3V95PmYdl2RnYd7fLkjgDcvPNSjxVdzard2cFnp8Qt3jQi+1EwykvGkn3BGw434+91FPPhe6i06K wgv7aW1FuIpYb+y89HbLEyBQy4J3HI5HA9KrWvg25064lezvdOkRxCFN/pxnkXy4kjHziVeuzPTq aWoG5qmqy2d1aWVnarc3t3vMaSS+WiogG5mbDEAblHAJyw9zVLUfEV3pmim6n0iRr/zjClnFLuEp ALEo+BkbFZuQD8uMCrmqaXNd3dpfWVzHb3tqHVGliMiMjgblZQQeqqcgjG36iqK+GJLm/iu9V1KS 8MYkZY1DRKjvtGVw2QAq4AyfvMSTmmA3UPFXkX9vaWENpcGe2W5ia4vPs/nKxOFiyp3txkjjGV55 qBvFt1Jq15YwWWnw/ZRFu/tDUTbuS6B8bRG/TODz1pV8KXkFidPg1G1lsApjS1vrIzoib2KADeOV VtuTkEKvA5zDb+Cp7C7mltLzT5UkjgjxqGnG4dfKjWMHcJF67cnjrS1AuxeJ5rjWprKGxheOC5Fv Iv2oC5A4HmeTt/1fOc7s45xXR1zl34bu767iNzf201vFdLcoz2mbiIhw+1Jd/wAq5GPu528e9dHT AKKKKBBRRRQAUUUUAFc/8OP+Qbrn/Yev/wD0ca6Cuf8Ahx/yDdc/7D1//wCjjUyKidlRRRUFBRRR QAUUUUAFFFFAHF+M/wDka/BX/YQn/wDSaSuirnfGf/I1+Cv+whP/AOk0ldFVx2JkFFFFUSFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHJ+Lf+Rl8F/8AYXP/AKJkrvq4Hxb/ AMjL4L/7C5/9EyV31RLctbBXP+If+Q54T/7Csn/pFdV0Fc/4h/5DnhP/ALCsn/pFdVIzOufGksEn iNPsyAWMbtp7tnFy6BVdT/uyuq8f3hUeneK7rU9bktItY0OILeSW62jxu07rG5UnIkABO1iOOmOt ak/g+wubWyhllnJtL9r9ZMjc7NKZWVuOULHp/sj0pdE8OXWiiCFNevJrOHd/o8kMOGzk8sEDdTnr QBkWnjySaXw+ksMCpdwGbUZgSEtj5MkiqOep8l856BfcVZ1HxVeWPhew1Kf7HZT6hdLHD9qB8uGN izAyfMDu8tSSMj5uKevgDSRpUGnvJcPDHf8A26QswJmbBXY3H3Np24GOB9a3rrTYrvUbC8kd91kz vGgI2lmUpk/RSw/GgDG0fXrq91Gxtftum30c8E9w9xZxsqhUaNFAyzclmfnP8NUrbxpcS6xZQNbR GynuLiKSZc5iUTGGBj673Vh+Irdv9Ea61Eaha389ldeT9nd41Rw0edwGGBwQScEevIPGK0fhDTYr O6tEaYQz2UVkBuBMax7yrKcZ37nLZOeQDQBSsPEWp667W+lpZxyJ5kr3E6MyLF50kcICBgWZhGWJ yAOOuRTtR1LxNE+jxwJpttPfS/Z5IZ42l2OFkdnDK65XanAxnkZx0qeHwmtilsum6nd2Ris4rKRo 1jYypHnax3KcONzfMPU5B4xoR6FaxXGlyI0m3TYXigRm3feCruYnknCkZ/2jmgDFg8R6pc3kulQR Wsl/9oeFJyjLCqRRxGWQruJOJJdgUEdsmq194yv9KkNnc21vLeW14Eumh3bTa+UZWlVScqwUY2kn nucitk+GY4o4ns724tryGa4lS5UKxPnOXdGUjBUnb6H5F54pbLwvZ2l+l8809zdYm82Scg+c0nlg swAA4WNVAGAFyMUAZ2oeKbqCS9MAt1s4L5LQ3jxvIkKmEStI4U8jLKoPABOSabdXV1eN4TnvFtxK dXcB7Zw8cqi3uNrqcnhhg4zxnFW7HwiukWNtbaVql7amAy/MdsgkV2BwwYEEqFUA8EAd8mq99pkG jv4SsbdnaOPVnO6Qgsxa3uWYnAA5JJ4AHoBQB1lef/Dr/kB6j/2F73/0c1egV4/4Z8Yab4Zt9T03 U4NSjuV1S7cqlhM42tKxByFx0qo7iZ6dRXGf8LQ8O/3NV/8ABZP/APE0f8LQ8O/3NV/8Fk//AMTV 3RNjs6K4z/haHh3+5qv/AILJ/wD4mj/haHh3+5qv/gsn/wDiaLoLHZ0Vxn/C0PDv9zVf/BZP/wDE 0f8AC0PDv9zVf/BZP/8AE0XQWOzorjP+FoeHf7mq/wDgsn/+Jo/4Wh4d/uar/wCCyf8A+Jougsdn RXGf8LQ8O/3NV/8ABZP/APE0f8LQ8O/3NV/8Fk//AMTRdBY7OiuM/wCFoeHf7mq/+Cyf/wCJp8nx L8PxEB11HJGRssZJBj6qDj6Hmnuri62OworjP+FoeHf7mq/+Cyf/AOJo/wCFoeHf7mq/+Cyf/wCJ pXQ7HZ0Vxn/C0PDv9zVf/BZP/wDE0f8AC0PDv9zVf/BZP/8AE0XQWOzorjP+FoeHf7mq/wDgsn/+ Jo/4Wh4d/uar/wCCyf8A+JougsdnRXGf8LQ8O/3NV/8ABZP/APE0f8LQ8O/3NV/8Fk//AMTRdBY7 OiuM/wCFoeHf7mq/+Cyf/wCJo/4Wh4d/uar/AOCyf/4mi6Cx2dc/8OP+Qbrn/Yev/wD0cazP+Foe Hf7mq/8Agsn/APia0Phi5n0DUrsRTRxXWsXlxF50ZRmR5SVOCAelTJjR2tFFFQUFFFFABRRRQAUU UUAZGv8AhjSPE8NvFq1s8y28hkiKTyRMjYIyCjA9Caxf+FXeEv8Anyvf/Brdf/Ha7GigDjv+FXeE v+fK9/8ABrdf/HaP+FXeEv8Anyvf/Brdf/Ha7GigDjv+FXeEv+fK9/8ABrdf/HaP+FXeEv8Anyvf /Brdf/Ha7GigDjv+FXeEv+fK9/8ABrdf/HaP+FXeEv8Anyvf/Brdf/Ha7GigDjv+FXeEv+fK9/8A Brdf/HaP+FXeEv8Anyvf/Brdf/Ha7GigDjv+FXeEv+fK9/8ABrdf/HaP+FXeEv8Anyvf/Brdf/Ha 7GigDy3xD4L0LSta0Ozs7e5SC/nMdwHvZ5Cy5QcFnJX7x5Ug/kK6H/hV3hL/AJ8r3/wa3X/x2m+M v+Rn8Kf9fTf+hR12db1P4cPn+ZlD45f10OO/4Vd4S/58r3/wa3X/AMdo/wCFXeEv+fK9/wDBrdf/ AB2uxorA1OO/4Vd4S/58r3/wa3X/AMdo/wCFXeEv+fK9/wDBrdf/AB2uxooA47/hV3hL/nyvf/Br df8Ax2j/AIVd4S/58r3/AMGt1/8AHa7GigDjv+FXeEv+fK9/8Gt1/wDHaP8AhV3hL/nyvf8Awa3X /wAdrsaKAOO/4Vd4S/58r3/wa3X/AMdo/wCFXeEv+fK9/wDBrdf/AB2uxooA5Ww+HPhfTdSttRtr G4+1Wr74XlvriUI2CM7XcjoT2rqqKKACuf8AEP8AyHPCf/YVk/8ASK6roK5/xD/yHPCf/YVk/wDS K6oAf4wdv+EZubZH2PfPHZKw6jznWMke4DE/hXG3F7frczWUk80R0KCOyurtThxDNcIPNB/veRFu LD7pcntXpxAPUA1gz+LdLtvsTSLMJL2/fT4lCAsXSVoix54TcOv+0OMnFAGRa2WhP4ja00mK1l0o 2Eh1NI23wliyGIt1UyYEpz1x1/hqTwfYaRoPg+HXZLS3tJJrU3dxKsYDKjkybOOcKCAB7CtKDxJZ Ncz2Gnadc3EkXnEJAkaLJ5bojlSzKPvuw5xkxv6DMen+LINSWx3aPqEEN9MYbd5vJKuwV2PCyMcA Rtzj0xnNAHF3uo6lpq65farBc2NzrGlylVuJY9kbLIscSrtY42idMkgZOT64saoNKhimsvCk0TWk untYXLWsu6ISzyRRQklTt8wb5G45xnPUV2d54jsI7u4sTaz3N1HMtukEaKWmcoshC5IGFVlJLEAZ HPSi38R2LtDa/Y7mC4a8+xtauihopPLMuThiu3YpbcpP55oA4N9VleHw/bzNItloIdroDgyy2sLl +/RSsY9zIe61rr4XsZpvB+m6lp0E92lo015JImWcRxhWUnuPNnVvqK6HVPE1tpsWpP8A2VeXUOnt sunhEQC7kWQ/fdSeGXgZOTVubWxaaRJqV9pl5amNxGIJPKaVizKq42Oy8sQOooA5S70bQLDX9c1I aPaGHRtMjmCCEbTL+8cn6hUjx/vVzsEel2XhC5yPDP20WC2xvLK+EtwHl2wmR/lG0fvCSc8V6Vqn iGx0u6e0mhlllaNHKRqp3GSQRIvJAyzHAzx8pyRiqT+IbSGMRnQb0Xkl0LP7EI4fMZvLMuc79hXa pOd3bHWgCroK6QPFAXw08TabFZOl39lk3QeaXQxAYJXeFEucc4YZ6itDxH/yFfC//YVP/pLcVqab cSXFsWk0240/axUQzmIkjrkeW7DHJ754PFZfiP8A5Cvhf/sKn/0luKAOgooooAKKKKACiiigAooo oAKKKKACiiigArjPhv8A8gjUP+v1/wD0Fa7OuM+G/wDyCNQ/6/X/APQVreH8KfyMpfxI/M7Oiiis DUKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AoopH3bG2AFscA9M0Acb4y/5Gfwp/wBfTf8AoUddnXj+veL7i91rT5Z9PWCbS52Yx+Znc25cg8cf dr0bwxrNzr2lm+ntFtkZysYD7twHU9B34/CuyvRnGlFvp/mc9KpGU5JG1RRRXGdAUUUUAFFFFABR RRQAUUUUAFFFFABXP+If+Q54T/7Csn/pFdV0Fc/4h/5DnhP/ALCsn/pFdUAdBXBT+CNUkttVkS9t l1CS/E2nSHcVtovtInbIxyxJOR0O1ee9d7RQBzun+HZdIubyWxMIVdPhs7EOxJGzzGLOcdWZxkjO cZqKHwmhTQLW7WGey0uyaIoc/PNtjVXxj+6JPf5q6esTWbm7l1fTtHtLk2n2qOaea4QKXEcewFU3 AjcTIvJBwAe+CADKs/C17o10uoafHZyXC3F2TbPI0aNFKybcOFJDBYYh0I+8PQ0f8I7q8erR68TZ z6gZ3kktTM6RKpjEaBX2kkqAeSoyZG6cCqmv63d6bpkmk2WvxTajNJKIrtgha3jRQSHAG0vu+QcD 72eqk1PqOs3l7a6dqdvdXcWlNZLcXR00RvNCzhWVnRwSUC5OFGfUEdAC5/wjd3JosttNJbm5vdSj vb0gnZtEqMUXjJ+RFTJxnGeOlaev6fc6jYQx2jR+bDdQ3ISViqSeW4faWAJHKg5weQOK5KO/1nUt VuIhda3PBbJb24uNKS2SKSQxK7ufN5GfMHA4AFXri71OLW1MurXUdnJdRRWdxFHFLbSAbVeOUBdy uzBxnIGSMEEYoAsT6Jq9093f3Nrpk812YoptPmkLwm3RXwnmFPvb5C+dmOMe9Zs3hDVnWwWaGyvr a3knkWyn1GZVg3BFjVJfLZmCgSdQPv4HAFd9RQBR0e0NjpUNu1rDasm7MMMzTIuSTw7KpPXPIHpW b4j/AOQr4X/7Cp/9Jbiugrn/ABH/AMhXwv8A9hU/+ktxQB0FFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFcZ8N/wDkEah/1+v/AOgrVjx4mpRaOt/pt5PA1u371YnI3Ie/4HH4E1wngr+1L3W47K2vbiG1 3+fcCNyAQMZz7ngfjXbRo81CUr/0jmqVLVUrHs1FFFcR0hRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFAENzd21nGJLq4igQnAaVwoz6ZNVf7e0f/oLWP/gQn+Ncp4/srXUPEHg60vba G5tpNQm3wzRh0bFvIRlTweQDVv8A4Qjwn/0K+i/+C+L/AOJppXE3Y6D+3tH/AOgtY/8AgQn+NH9v aP8A9Bax/wDAhP8AGuf/AOEI8J/9Cvov/gvi/wDiaP8AhCPCf/Qr6L/4L4v/AImnyi5joP7e0f8A 6C1j/wCBCf40f29o/wD0FrH/AMCE/wAa5/8A4Qjwn/0K+i/+C+L/AOJo/wCEI8J/9Cvov/gvi/8A iaOUOY6D+3tH/wCgtY/+BCf40f29o/8A0FrH/wACE/xrn/8AhCPCf/Qr6L/4L4v/AImj/hCPCf8A 0K+i/wDgvi/+Jo5Q5joP7e0f/oLWP/gQn+NH9vaP/wBBax/8CE/xrn/+EI8J/wDQr6L/AOC+L/4m j/hCPCf/AEK+i/8Agvi/+Jo5Q5joP7e0f/oLWP8A4EJ/jR/b2j/9Bax/8CE/xrn/APhCPCf/AEK+ i/8Agvi/+Jo/4Qjwn/0K+i/+C+L/AOJo5Q5jmfGenaff+I7W5sdQsyl4wSdlnUiNh/EeeBj9R716 BaanoVjZw2sGp2KxQoEUfaE6D8axf+EI8J/9Cvov/gBF/wDE0f8ACEeE/wDoV9F/8F8X/wATW06k pxjF9CIwjGTkup0H9vaP/wBBax/8CE/xo/t7R/8AoLWP/gQn+Nc//wAIR4T/AOhX0X/wXxf/ABNH /CEeE/8AoV9F/wDBfF/8TWPKXzHQf29o/wD0FrH/AMCE/wAaP7e0f/oLWP8A4EJ/jXP/APCEeE/+ hX0X/wAF8X/xNH/CEeE/+hX0X/wXxf8AxNHKHMdB/b2j/wDQWsf/AAIT/Gj+3tH/AOgtY/8AgQn+ Nc//AMIR4T/6FfRf/BfF/wDE0f8ACEeE/wDoV9F/8F8X/wATRyhzHQf29o//AEFrH/wIT/Gj+3tH /wCgtY/+BCf41z//AAhHhP8A6FfRf/BfF/8AE0f8IR4T/wChX0X/AMF8X/xNHKHMdB/b2j/9Bax/ 8CE/xo/t7R/+gtY/+BCf41z/APwhHhP/AKFfRf8AwXxf/E0f8IR4T/6FfRf/AAXxf/E0cocx0kGr abdTCG31C0llbokcysT+ANXK8v1zw/ouj+K/Bs2maRp9lK+qlWe2tkjZl8mTglQMivUKTVikFc/4 h/5DnhP/ALCsn/pFdV0Fcz4ru7ax1Pwtc3dxFbwJqr7pZXCKubO5AyTwOSB+NIDpqKx/+Es8N/8A QwaV/wCBsf8AjR/wlnhv/oYNK/8AA2P/ABoA2KpajpNlqgh+1RuXhYvFJHK0UkZIwdroQwyDg4PN VP8AhLPDf/QwaV/4Gx/40f8ACWeG/wDoYNK/8DY/8aALOn6Lp2lOz2VssLNGsbEEnKqWIHJ9XYn1 LEnJOaqSeEtEkSFDaMqRQLbBY55EDxL0RwGAdRk8Nkcmnf8ACWeG/wDoYNK/8DY/8aUeK/DhzjX9 K46/6ZH/AI0ARr4S0aO8a6ihuIpWl85hFeTIhb12BwvYcYxUyeHNKS/+2LbN5nnGfZ5zmISnq4jz sDck7sZySetM/wCEs8N/9DBpX/gbH/jR/wAJZ4b/AOhg0r/wNj/xoA2KKx/+Es8N/wDQwaV/4Gx/ 40f8JZ4b/wChg0r/AMDY/wDGgDYrn/Ef/IV8L/8AYVP/AKS3FWP+Es8N/wDQwaV/4Gx/41katrmk alrfhiCw1SyupRqZYxwXCOwH2afnAPTkUAdfXBD4mSXFxdLp3hHXb6C3uJLf7RCkex2RirYy+cZF d7Xn/wAOv+QHqP8A2F73/wBHNTSuJsl/4WHqX/Qh+Iv++Yv/AIuj/hYepf8AQh+Iv++Yv/i66miq 5Rcxy3/Cw9S/6EPxF/3zF/8AF0f8LD1L/oQ/EX/fMX/xddTRRyhzHLf8LD1L/oQ/EX/fMX/xdH/C w9S/6EPxF/3zF/8AF11NFHKHMct/wsPUv+hD8Rf98xf/ABdH/Cw9S/6EPxF/3zF/8XXU0Ucocxy3 /Cw9S/6EPxF/3zF/8XR/wsPUv+hD8Rf98xf/ABddTRRyhzHJzePr64hkhl8A+IXjkUqylIsEHgj7 9YfhjW7zw1FchfBHiGaSaTPmeXEMIPur9/r1zXpFFWm1FxT0ZLSbT7HLf8LD1L/oQ/EX/fMX/wAX R/wsPUv+hD8Rf98xf/F11NFRylcxy3/Cw9S/6EPxF/3zF/8AF0f8LD1L/oQ/EX/fMX/xddTRRyhz HLf8LD1L/oQ/EX/fMX/xdH/Cw9S/6EPxF/3zF/8AF11NFHKHMct/wsPUv+hD8Rf98xf/ABdH/Cw9 S/6EPxF/3zF/8XXU0Ucocxy3/Cw9S/6EPxF/3zF/8XR/wsPUv+hD8Rf98xf/ABddTRRyhzHLf8LD 1L/oQ/EX/fMX/wAXXQ+GPEcPijSXvorS5tGjnkt5YLkAOkiNtYHBI61Yrn/hx/yDdc/7D1//AOjj SasNO52VFFFSMKKKKACiiigAooooA4vxn/yNfgr/ALCE/wD6TSV0Vc74z/5GvwV/2EJ//SaSuiq4 7EyCiiiqJCiiigAoorP1yznv9GuYLWTy7raHt3zgLKpDJn23AZ9s0AaFFefXmrNrKxayk09vpLTW 9nI4dozHG2HlJIxt+Yxxk8Y2tyKTVTFp19NZaPcSfYlW0knjWcusMhu4wuCSdpZS+QOu0HvyXGeh UV51oOnapdBb63tli2ancSyXa38hknRLiQGPysBTkDaMtgdau65K2q6haGSJYnSCRv7L1K5a23jI /eLJGWUsMYwc4Bz8ueS4HcUV5jZxXeu6jIbW0kugNJtBHLeak8MkRYzDdujU7ycA7hjOAe9O0y3I 1rUY9U/s27nt7yKN7m61N4JDiCHJWMIQRncRyMkkcUrhY9MoriLdtMlS51HVtRng1SHUZIsxzvvi xMRFGsYzkMmzjadwYnvWXBb3OqX+nQ/ZYb8CPUnMdzeSQKCLsAHKqxJAOMY6U7gel0VwEzGDUp7C eVrbTDqkEFxsnYBE+xqVTfwQpkCKTxnOD1rp9CXTYJL600y6lmjhlAeIuzpAxUfKrH8CVycE9s0A bFFFFAgooooAKKKKAOT8W/8AIy+C/wDsLn/0TJXfVwPi3/kZfBf/AGFz/wCiZK76oluWtgpkkUcy 7ZY1deuGGRT6KkZX+wWf/PpB/wB+xR9gs/8An0g/79irFFAFf7BZ/wDPpB/37FH2Cz/59IP+/Yqx RQBX+wWf/PpB/wB+xWXq9lard6OFtoQGvsHEY5HlSVuVk6z/AMfmjf8AX9/7Skq6fxff+RMti99g s/8An0g/79ij7BZ/8+kH/fsVYoqCiv8AYLP/AJ9IP+/Yo+wWf/PpB/37FWKKAK/2Cz/59IP+/Yp0 dpbROHjt4kYd1QA1NRQAV5/8Ov8AkB6j/wBhe9/9HNXarqdk+oSWAuY/tcYBaEnDYIzwO/HpXFfD r/kB6j/2F73/ANHNVpNPUlu6OuoooqiQooooAKKKKACsmbxLpUF/FZS3BWeS6Noo8tsebsV8Zxgc MvPTJxWtXDal4W1G+1G6kWNUDXk1zBLvHyP5MQib14kj/ShjOtt9Us7rU7zToZd11ZiMzptPybwS vPQ5AJqoPEumNfi08yfcZjAJjbyCEygkFBJt2lsgjr1GOvFZGmaFrEd/d3xuFsbi9ggkncKsv7wP OzR8nookjUHuFoGl6lHrAe1sp7SQ3vmyzw3QNpNCXyxaFmJEhXjhR83O7FAF6Dxpos9ot15l1FC8 TzRvNaSosiKhclWK4b5QTgHJAPpU9t4o0+5t5Lkpe29tHD5zTXNpJEm3joWUAnnoOTXPWfguaLwO lrcSXU2pR6c8UVvJc5iimaFk+UDjoxGTngmo7XQdRl0RrH+z9Ut7hIoXVr3URNCzxOjhAokbaGKY zjgH8KWoHTJ4n0xvMDvcQPGUBS4tpImIdwisFZQSNxAyOmecUReJrGe8kt44r5vLleJ5hZymIMhI b59u3ggjOaz9TXW9btWhGlfZIFeB9s8qGV2WeN2I2MVChVbqckkcDHLtJ8OSWpv7maW7W4lurqRI RdsYiru5U7M7ehB6dfemBcl8VaXHHA6tczCaBLkC3tJZSkTDKswVTtBwevPB9DWtBNFcwRzwyLJF KodHU5DKRkEfhXI6Jpuq+G4gy6bJetcWNsjpHNGphmiiCFTuIGw4ByuT14rrLQXC2UAu/J+0CNfN 8kEJuxztzzjPTNAE1FFFAgooooAKKKKACuf+HH/IN1z/ALD1/wD+jjXQVz/w4/5Buuf9h6//APRx qZFROyoooqCgooooAKKKKACiiigDi/Gf/I1+Cv8AsIT/APpNJXRVzvjP/ka/BX/YQn/9JpK6Krjs TIKKKKokKKKKACsO58TRQard6emnX9w9pGsk8kCIVQMCR1YMfunoDW5XH6n4MbVdX1u7luHhN3BC lq8U7jayBs70GFZSSODnIz0oGW4vFNlcyz2mm6Re38CKju9tHGIyJUEgOGdSchsnjuafNrOk6X9o toNMmaztXzdS2tsDDAww2SBySOCdobHfGKwl8MaqmsXl8+k20guEg2x2+rTWyRFIlUqFRcEZHGe1 aV1p3iGwtdQs9Ht7CaO7mlnElxIQU8wEspGOSGOQehHBA60gNZdd0+LTtWu4lb7PpjOZ/LUfMRGJ SV55yHHPc5qjqviDS3uV0+bSp9Rm+1NAkKwxv+8SNZCRvYDhWHP1rMHhzVbTRNS0WwtoWtdTiVPP uJ8Pb5gSFtygEMQEyMHknHGMme68IT32vpc3DL9k/tCW5YRzvG+xrdI1wVwc7l556flQBdfxZYR3 UUNvpt7PfTPJC0EUSCRDEFYhtzAYxICME/eoTUdGvdfh0680gw6lcW5uQLq3jJwGKhSwJ+bCkgeg /CsGfwZqUM2nrFBDeQWU1yQxvpLeWZZAm1ndFyXGCCe4APsLcvhnVnkW/tI7e0vbeCEWiSXbzhXW SXdudlyQY5SPx9qALTeK9Hn1VDbaTc3uoLcT2iPFDHvzEFLkMzD5cOMc81o2mvae+tW+lyWc1lfz W7TpHMiA4LtlcqSNx2FsA8gZ7HHMXHge9t7+2e1giubW3nlZYzfSW7lGhhjUl0Gc5ibI78VqReF7 i6eWSdFsm+yRJblLlrl4Jo5ZHD73ALffHXqCV6UagTz+K7PyrcroeoXEOouYkZI4isr4bKkFxziM 9ewqe18Q6fbOlnb6ZdQWscqW7yRwKIYJWxhDtPXLAEgFQT161XsvD+oRaT4bguGt/P0+7NxcmNjt IMco+XIyeZB1qO+0LUptYe4t7W1gnedXXUbe5eJvLBHEkQGJGwCvJIIx92gDraKKKYgooooAKKKK AOO8beeNb8IG1EZuP7UbyxJnbu8iTGcc4qbQ5PFreKLkakArfZ22LLnycbl+7t4z+vrSeLf+Rl8F /wDYXP8A6JkrvqaqcqasncHDms7mb/xO/wDqH/8Aj9H/ABO/+of/AOP1pUVnzeRXL5mb/wATv/qH /wDj9H/E7/6h/wD4/WlRRzeQcvmZv/E7/wCof/4/R/xO/wDqH/8Aj9aVFHN5By+Zm/8AE7/6h/8A 4/Ve502/1KW1W+e3WCCbzT9neRHJ2sowwII+961tUU1NrYOVPczf7DtP+e2of+DCf/4uj+w7T/nt qH/gwn/+LrSopc8u4csexm/2Haf89tQ/8GE//wAXR/Ydp/z21D/wYT//ABdaVFHPLuHLHsZv9h2n /PbUP/BhP/8AF0f2Haf89tQ/8GE//wAXWlRRzy7hyx7HF3XgCK+8QSX095Mtt8uxBKzyEgDq7Ekc /X8Ko/DhQugX6jOF1a9Aycn/AFzV6FXn/wAOv+QHqP8A2F73/wBHNWjqznZSexKhGN2jrqKKKQBR RRQAVleJtRn0jwvqmo2wQz21tJLHvUsu4AkZA5NatVNU06HVtLutPuS4huYmicocNgjBxQM4i78Z 6lbWGpyWtzBfGztGkkkOmzW3ky7k2Kwdvm3KzEAY+771pReIL9LJzHeR3tzLPDbQCTTZbRY2diNz b2y4ABOB6YzzWtrfhiy10yG4kuImltzbSGFgN6FgwByD0IyD2yfU0f8ACOiW2mt73VdRvY5NpXzm jBidWDK6FEUhgQD+FLUDK1PXNZ0KZbW7ls7qSbynhmjgaP5ftEUUispdu0ykEEd+OObmra7d2WsS WkSxeWosSCykn99dGJ+/93p70ieDLXzruW61HUbx7mPYxuJVzGQwcGPao2EMAeOCcEg4q0nhq33S yXV5eXdxJJA7TzMm4CGQSIoCqFC7s5wMnJyaYHNaf4w1G5vY4ftMEtxNqEkC2Q02ZT5STmNmWbds O1PmJxjjHek0DxZqepaYt9PfxGQ28sptV0mZFyqsQPOLbSOAffpXU/8ACOWQ02KyV50EN013FKrD ekhkaQkHGMZZhjHQkGqlh4Rj0+zWxi1jU2sljaMWztEU2sCMf6vPfPWlqBkweMdQk0PRJDFAdRuL 6K3vVCEKkfmojOozxnzIiMk/6wVX0DxZqepaYt9PfxGQ28sptV0mZFyqsQPOLbSOAffpXSJ4T01J WlHnb2+zZO8dYGVlPTv5aBvUKOlQ2HhGPT7NbGLWNTayWNoxbO0RTawIx/q8989aNQKFj4n1DUId KsyILbU55GiudyF1XMDyJIoyMq2Aev8AeXOQaistX8TSaZql351rdPa3r2axQ2TZAWVVaXAkJbC7 jsGCfWt//hHNP/tDS7/a/wBp02IxQuG+8pUrhuOcAkj0JPqaT/hGrL7DdWqyXCC4u2vfMV8PHKW3 ZU44wexz6HNADPDmqS6lDcia8trpoZAu6OB4HGQDh4n5Q5zjnkelbdUNO0pNPluJ2uJ7q5uNvmzz ldxC52rhQFAGT0Hc1fpgFFFFAgooooAK5/4cf8g3XP8AsPX/AP6ONdBXP/Dj/kG65/2Hr/8A9HGp kVE7KiiioKCiiigAooooAKKKKAOL8Z/8jX4K/wCwhP8A+k0ldFXLeP72107xB4Our25htraO/m3z TyBEXNvIBkngckCrf/Cb+E/+ho0X/wAGEX/xVXHYlm9RWD/wm/hP/oaNF/8ABhF/8VR/wm/hP/oa NF/8GEX/AMVVCN6isH/hN/Cf/Q0aL/4MIv8A4qj/AITfwn/0NGi/+DCL/wCKoA3qKwf+E38J/wDQ 0aL/AODCL/4qj/hN/Cf/AENGi/8Agwi/+KoA3qKwf+E38J/9DRov/gwi/wDiqP8AhN/Cf/Q0aL/4 MIv/AIqgDeorB/4Tfwn/ANDRov8A4MIv/iqP+E38J/8AQ0aL/wCDCL/4qgDeorFTxh4ZlV2j8Q6V IqDLsl5GwQerEHgcd6j/AOE38J/9DRov/gwi/wDiqBG9RWD/AMJv4T/6GjRf/BhF/wDFUf8ACb+E /wDoaNF/8GEX/wAVQM3qKwf+E38J/wDQ0aL/AODCL/4qj/hN/Cf/AENGi/8Agwi/+KoA3qKwf+E3 8J/9DRov/gwi/wDiqP8AhN/Cf/Q0aL/4MIv/AIqgDeorB/4Tfwn/ANDRov8A4MIv/iqP+E38J/8A Q0aL/wCDCL/4qgDeorB/4Tfwn/0NGi/+DCL/AOKo/wCE38J/9DRov/gwi/8AiqAKPi3/AJGXwX/2 Fz/6Jkrvq8v1zxDour+K/BsOmaxp97KmqlmS2uUkZR5MgyQpPFeoVnLcpBRRRSGFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFef8Aw6/5Aeo/9he9/wDRzV6BXmGhJ4t8NxX9ivg65vY31C5uI54r+2VX R5GZThnBHB704uzEzvaK5f8At3xb/wBCBe/+DK1/+Lo/t3xb/wBCBe/+DK1/+Lq+ZE2Z1FFcv/bv i3/oQL3/AMGVr/8AF0f274t/6EC9/wDBla//ABdHMgszqKK5f+3fFv8A0IF7/wCDK1/+Lo/t3xb/ ANCBe/8Agytf/i6OZBZnUUVy/wDbvi3/AKEC9/8ABla//F0f274t/wChAvf/AAZWv/xdHMgszqKK 5f8At3xb/wBCBe/+DK1/+Lo/t3xb/wBCBe/+DK1/+Lo5kFmdRRXL/wBu+Lf+hAvf/Bla/wDxdV7T xbruoxtJp3g+4vI0Yo7x30ChW/u/OVOeR0496pK6bWyE9HY7CiuX/t3xb/0IF7/4MrX/AOLo/t3x b/0IF7/4MrX/AOLqeZDszqKK5f8At3xb/wBCBe/+DK1/+Lo/t3xb/wBCBe/+DK1/+Lo5kFmdRRXL /wBu+Lf+hAvf/Bla/wDxdH9u+Lf+hAvf/Bla/wDxdHMgszqKK5f+3fFv/QgXv/gytf8A4uj+3fFv /QgXv/gytf8A4ujmQWZ1FFcv/bvi3/oQL3/wZWv/AMXR/bvi3/oQL3/wZWv/AMXRzILM6iuf+HH/ ACDdc/7D1/8A+jjVf+3fFv8A0IF7/wCDK1/+Lq/4A07UtO0W+Oq2Rsrm71O6uxA0qSFFkkLAEqSM 4PrUydxpHV0UUVJQUUUUAFFFFABRRRQBWvdOsdShEN/Z291Erbgk8SuAfXBHWqH/AAifhv8A6F/S v/AKP/CtiigDH/4RPw3/ANC/pX/gFH/hR/wifhv/AKF/Sv8AwCj/AMK2KKAMf/hE/Df/AEL+lf8A gFH/AIUf8In4b/6F/Sv/AACj/wAK2KKAMf8A4RPw3/0L+lf+AUf+FH/CJ+G/+hf0r/wCj/wrYooA x/8AhE/Df/Qv6V/4BR/4Uf8ACJ+G/wDoX9K/8Ao/8K2KKAMf/hE/Df8A0L+lf+AUf+FH/CJ+G/8A oX9K/wDAKP8AwrYooA898U6HpFn4g8NwW2lWMEVxclZo4rdFWUbk4YAcjk9fU11X/CJ+G/8AoX9K /wDAKP8AwrE8Zf8AIz+FP+vpv/Qo67Ot6n8OHz/Myh8cv66GP/wifhv/AKF/Sv8AwCj/AMKP+ET8 N/8AQv6V/wCAUf8AhWxRWBqY/wDwifhv/oX9K/8AAKP/AAo/4RPw3/0L+lf+AUf+FbFFAGP/AMIn 4b/6F/Sv/AKP/Cj/AIRPw3/0L+lf+AUf+FbFFAGP/wAIn4b/AOhf0r/wCj/wo/4RPw3/ANC/pX/g FH/hWxRQBj/8In4b/wChf0r/AMAo/wDCj/hE/Df/AEL+lf8AgFH/AIVsUUAZtr4e0SxuFuLTR9Pt 50+7JFbIjL24IGa0qKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigArjPhv/AMgjUP8Ar9f/ANBWuzrjPhv/AMgjUP8Ar9f/ANBWt4fwp/Iyl/Ej8zs6 KKKwNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigDjPGX/Iz+FP+vpv/Qo67OuM8Zf8jP4U/wCvpv8A0KOuzrep/Dh8/wAzKHxy/roFFFFY GoUUUUAFFFFABRXn0XxA8Q38l02k+Bp72zhuZbdbj+04I95jcoTtbkcg1L/wmXjP/onM/wD4OLb/ ABp2YXO8org/+Ey8Z/8AROZ//Bxbf40f8Jl4z/6JzP8A+Di2/wAaLMLneUVwf/CZeM/+icz/APg4 tv8AGj/hMvGf/ROZ/wDwcW3+NFmFzvKK4P8A4TLxn/0Tmf8A8HFt/jR/wmXjP/onM/8A4OLb/Giz C53lFcH/AMJl4z/6JzP/AODi2/xo/wCEy8Z/9E5n/wDBxbf40WYXO8org/8AhMvGf/ROZ/8AwcW3 +NH/AAmXjP8A6JzP/wCDi2/xoswud5RXB/8ACZeM/wDonM//AIOLb/Gj/hMvGf8A0Tmf/wAHFt/j RZhc7yiuD/4TLxn/ANE5n/8ABxbf40f8Jl4z/wCicz/+Di2/xoswud5RXB/8Jl4z/wCicz/+Di2/ xo/4TLxn/wBE5n/8HFt/jRZhc7yiuD/4TLxn/wBE5n/8HFt/jR/wmXjP/onM/wD4OLb/ABoswud5 RXB/8Jl4z/6JzP8A+Di2/wAaP+Ey8Z/9E5n/APBxbf40WYXO8org/wDhMvGf/ROZ/wDwcW3+NH/C ZeM/+icz/wDg4tv8aLMLneUVh+E/ETeJtFN9JYvYzJcS28tu0gkKPGxUjcODyK3KQBRRRQAUUUUA FFFFABXGfDf/AJBGof8AX6//AKCtdnXGfDf/AJBGof8AX6//AKCtbw/hT+RlL+JH5nZ0UUVgahRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF AHGeMv8AkZ/Cn/X03/oUddnXGeMv+Rn8Kf8AX03/AKFHXZ1vU/hw+f5mUPjl/XQKKKKwNQooooAK KKKAOC+H3/IAvP8AsK33/pQ9dXXKfD7/AJAF5/2Fb7/0oeurrVbEMKKKKBBRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBz/w1/wCQDqX/AGGb7/0e1dlXG/DX/kA6l/2Gb7/0 e1dlWRoFFFFABRRRQAUUUUAFcZ8N/wDkEah/1+v/AOgrXZ1xnw3/AOQRqH/X6/8A6Ctbw/hT+RlL +JH5nZ0UUVgahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFAHF+NGVPEvhVnYKoumJJOABujrq/7Qsv+fy3/AO/q/wCNVdY0DTtdSJdQgMnl ElCHKkZxnp9B+VZX/CvvDn/PpJ/3+b/GujmpyhFSbTXl5+pjaak2upv/ANoWX/P5b/8Af1f8aP7Q sv8An8t/+/q/41gf8K+8Of8APpJ/3+b/ABo/4V94c/59JP8Av83+NK1Hu/u/4I71Oy+//gG//aFl /wA/lv8A9/V/xo/tCy/5/Lf/AL+r/jWB/wAK+8Of8+kn/f5v8aP+FfeHP+fST/v83+NFqPd/d/wQ vU7L7/8AgEnijxSuiafBdWjW9yzXAR4/M5KlWJxjpyBzT9E8Z6RrW2NZvs9yf+WMxwSfY9D/AD9q 53xR4DtYdPg/sOxla6e4Ct+8JATa2ScnAGQOafonwzgi2zaxN5zdfIiJCj6t1P4Yrfkw3srt6/j9 xlzVueyWg/4ff8gC8/7Ct9/6UPXV1yfw7RY/Dl0iDCrql6APQfaHrrK5lsbsKKKKBBRRRQAVy8vi /wAtdeYWfyafbyz2zM/F0ItyyY442uu3v94GullV2hdY3CSFSFcrnaexx3rlbnwDYvpEFpaS/Zrh LeS3luhHuaZZImR9wyOpIf6qKBkMXjyOJZGvBp0yJaSXLPpt79o2bNuFcFRtLbsA56jFW9U8Raxo mkXmoajpFssUEBmVobwuAQVGx8ouD8xORkfKenGbF74TtLtnAcww3Fq1reRxqAJ1x8jezqejc8Ej 0xBqXhjUNZsLi11HWy6PAYEENv5a5LKS7ruO9vlwOgGTxzwtQG3vjjT47h49NmtNRWO2ad2t7pW2 kSRoFO3OM7yfwp661ro8QXGnSafpwiggS5eRbtyTGzOowPL+9+7Ptz1q3rXh1dYuPONyYj9ma3xs 3dZI3z1/6Z4/GrTaSrazdaj5xzcWaWpTb90K0jbs/wDbTp7UwOa0vx2brSDqt0+jeQtn9reC01Ay 3C/KCFKFBzkhTzwTW5HeeImDpJpNikjR74mW9ZkUgrlHPlgg4JIKhhwc44znWXhK6j0ddGvdRtbj Tvsv2VljsfKlKhdoO/eeRgHp1Fa1lp2ox3yXN/qv2lYojHHFFD5KsSRl3G47m44xgDJ454AMbSPF eo3ttplzd6faxQ6hetaR+VcM7LtEpYkFB3i4579qXWfGMmm6g1mkNlGRfC18+9uvJjANv52Sdpwf 4QKtw+FjbaFY2MN7tuLG5a6guGiyA7M5IKZ5GJGXqD3yKIfCxN/Bf3t4txdLeNdy7YNiOTAYQqrk 7QBg8knI/JagZU/j118hI4tLUy3clt9pk1A/ZcLEsm4S7Oc7tvThgRXVaTePf6bFcyPZuz5+azn8 2I4JHDYGenp1rAn8GzLdW0mn6jFbw2lxJPbQS2nmpEJE2sgAZflySQO2cdMY6LT4Lq2tBFdzwzSg n54YPKXH+7ub+dMC1RRRQIKKKKACiiigDk/A2q2Ok+GtTmvrmOBP7Zv8bjy379ug6n8KsWnxBh1L xFa2NrAIrN2YPPOcE4UkYHQcgdaw/C3hDT/EOh6lNKXhuhq98qzIc8ee+AQeCPyplp8Pry18RWsN /CLnTnZg8sLED7pIz3XnHt710UYYdwbk9f62MqkqqkuVaHpn9oWX/P5b/wDf1f8AGj+0LL/n8t/+ /q/41gf8K+8Of8+kn/f5v8aP+FfeHP8An0k/7/N/jWNqPd/d/wAE0vU7L7/+Ab/9oWX/AD+W/wD3 9X/Gj+0LL/n8t/8Av6v+NYH/AAr7w5/z6Sf9/m/xo/4V94c/59JP+/zf40Wo9393/BC9Tsvv/wCA b/8AaFl/z+W//f1f8aP7Qsv+fy3/AO/q/wCNYH/CvvDn/PpJ/wB/m/xo/wCFfeHP+fST/v8AN/jR aj3f3f8ABC9Tsvv/AOAb/wDaFl/z+W//AH9X/GuV+Gxzo9+R/wA/r/8AoK1b/wCFfeHP+fST/v8A N/jW1pWj2WiWhtrCLy42cuQWLEnpnJ+gpuVOMHGLbvYEpuScuheooornNQooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooA4L4ff8gC8/wCwrff+lD11dcp8Pv8AkAXn/YVvv/Sh66utVsQwooooEFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHP/DX/AJAOpf8AYZvv/R7V2Vcb8Nf+QDqX/YZv v/R7V2VZGgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5jpdj488PJeWVn 4f028tmvbieOZ9R2FlklZxldpx96r32/4i/9CnpX/g1/+wr0Cindisjz/wC3/EX/AKFPSv8Awa// AGFH2/4i/wDQp6V/4Nf/ALCvQKKOZhZHn/2/4i/9CnpX/g1/+wo+3/EX/oU9K/8ABr/9hXoFFHMw sjz/AO3/ABF/6FPSv/Br/wDYUfb/AIi/9CnpX/g1/wDsK9Aoo5mFkef/AG/4i/8AQp6V/wCDX/7C j7f8Rf8AoU9K/wDBr/8AYV6BRRzMLI8/+3/EX/oU9K/8Gv8A9hR9v+Iv/Qp6V/4Nf/sK9Aoo5mFk eaaf4k8ZavbtcaXoGnXcCuUZ3vDCQ3BxtIbPBHOe9W/t/wARf+hT0r/wa/8A2FW/hh/yLVz/ANfj f+gJXa1tiPdqyS2M6WsE2ef/AG/4i/8AQp6V/wCDX/7Cj7f8Rf8AoU9K/wDBr/8AYV6BRWPMzSyP P/t/xF/6FPSv/Br/APYUfb/iL/0Kelf+DX/7CvQKKOZhZHn/ANv+Iv8A0Kelf+DX/wCwo+3/ABF/ 6FPSv/Br/wDYV6BRRzMLI8/+3/EX/oU9K/8ABr/9hR9v+Iv/AEKelf8Ag1/+wr0CijmYWR5/9v8A iL/0Kelf+DX/AOwo+3/EX/oU9K/8Gv8A9hXoFFHMwsjmPAekalo/h6WLVoooby4vbi6eKKTeqeZI WA3YGetdPRRSGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRXB6d4q8VazA9zpui2ktuHKZMoBBGDjlh2I7VpClKabXQiU1HRne UVx39qeOf+hfs/8Av+v/AMXR/anjn/oX7P8A7/r/APF1fsH3X3on2q7P7jsaK47+1PHP/Qv2f/f9 f/i6P7U8c/8AQv2f/f8AX/4uj2D7r70HtV2f3HY0Vx39qeOf+hfs/wDv+v8A8XR/anjn/oX7P/v+ v/xdHsH3X3oPars/uOxorjv7U8c/9C/Z/wDf9f8A4uj+1PHP/Qv2f/f9f/i6PYPuvvQe1XZ/cdjR XHf2p45/6F+z/wC/6/8AxdH9qeOf+hfs/wDv+v8A8XR7B9196D2q7P7jsaK47+1PHP8A0L9n/wB/ 1/8Ai6P7U8c/9C/Z/wDf9f8A4uj2D7r70HtV2f3HY0Vx39qeOf8AoX7P/v8Ar/8AF0f2p45/6F+z /wC/6/8AxdHsH3X3oPars/uOxorjv7U8c/8AQv2f/f8AX/4uj+1PHP8A0L9n/wB/1/8Ai6PYPuvv Qe1XZ/cdjRXHf2p45/6F+z/7/r/8XR/anjn/AKF+z/7/AK//ABdHsH3X3oPars/uOxorjv7U8c/9 C/Z/9/1/+Lo/tTxz/wBC/Z/9/wBf/i6PYPuvvQe1XZ/cdjRXHf2p45/6F+z/AO/6/wDxdH9qeOf+ hfs/+/6//F0ewfdfeg9quz+47GiuO/tTxz/0L9n/AN/1/wDi6P7U8c/9C/Z/9/1/+Lo9g+6+9B7V dn9x2NFcd/anjn/oX7P/AL/r/wDF0f2p45/6F+z/AO/6/wDxdHsH3X3oPars/uI/hh/yLVz/ANfj f+gJXa15Z4MvPElrpE0ekaXBdW/2hizySBSH2rkcsO2Pzrov7U8c/wDQv2f/AH/X/wCLrbEUXKrJ 3X3ozpVEoJWf3HY0Vx39qeOf+hfs/wDv+v8A8XR/anjn/oX7P/v+v/xdY+wfdfejT2q7P7jsaK47 +1PHP/Qv2f8A3/X/AOLo/tTxz/0L9n/3/X/4uj2D7r70HtV2f3HY0Vx39qeOf+hfs/8Av+v/AMXR /anjn/oX7P8A7/r/APF0ewfdfeg9quz+47GiuO/tTxz/ANC/Z/8Af9f/AIuj+1PHP/Qv2f8A3/X/ AOLo9g+6+9B7Vdn9x2NFcd/anjn/AKF+z/7/AK//ABdH9qeOf+hfs/8Av+v/AMXR7B9196D2q7P7 jsaK47+1PHP/AEL9n/3/AF/+Lo/tTxz/ANC/Z/8Af9f/AIuj2D7r70HtV2f3HY0Vx39qeOf+hfs/ +/6//F0f2p45/wChfs/+/wCv/wAXR7B9196D2q7P7jsaK47+1PHP/Qv2f/f9f/i6P7U8c/8AQv2f /f8AX/4uj2D7r70HtV2f3HY0Vx39qeOf+hfs/wDv+v8A8XR/anjn/oX7P/v+v/xdHsH3X3oPars/ uOxorjv7U8c/9C/Z/wDf9f8A4uj+1PHP/Qv2f/f9f/i6PYPuvvQe1XZ/cdjRXHf2p45/6F+z/wC/ 6/8AxdH9qeOf+hfs/wDv+v8A8XR7B9196D2q7P7jsaKwPCWvT+INNmuLmCOGWKcxERk4OAD3+tb9 ZTg4ScWaRkpK6CiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcZ8Mv+RY m/6+n/8AQVrs64z4Zf8AIsTf9fT/APoK1vD+DP5fqZS/iR+f6HZ0UUVgahRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHGfDT/kXrv/AK/X/wDQErs64z4af8i9 d/8AX6//AKAldnW+J/iyMqP8NBRRRWBqFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFAHGfDf8A5BGof9fr/wDoK12dcZ8N/wDkEah/1+v/AOgrXZ1vif4sjKj/AA0FFFFYGoUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVxnwy/5Fib/r6f/wBBWuzrjPhl/wAi xN/19P8A+grW8P4M/l+plL+JH5/odnRRRWBqFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAcZ8NP+Reu/8Ar9f/ANASuzrjPhp/yL13/wBfr/8AoCV2db4n+LIy o/w0FFFFYGoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcZ8N/wDkEah/ 1+v/AOgrXZ1xnw3/AOQRqH/X6/8A6CtdnW+J/iyMqP8ADQUUUVgahRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABXGfDL/kWJv+vp//AEFa7OuM+GX/ACLE3/X0/wD6Ctbw/gz+X6mU v4kfn+h2dFFFYGoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQBxnw0/5F67/wCv1/8A0BK7OuM+Gn/IvXf/AF+v/wCgJXZ1vif4sjKj/DQUUUVgahRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBxnw3/AOQRqH/X6/8A6CtdnXGfDf8A5BGo f9fr/wDoK12db4n+LIyo/wANBRRRWBqFFFFABRRRQAUUUUAFFFFABRRRQAUVxU/xa8E29xLA+sSG SJ2jfZZXDgMDggFUIPI7Gmf8Lf8AA/8A0F5//Bdc/wDxugDuKK4f/hb/AIH/AOgvP/4Lrn/43R/w t/wP/wBBef8A8F1z/wDG6AO4orh/+Fv+B/8AoLz/APguuf8A43R/wt/wP/0F5/8AwXXP/wAboA7i iuH/AOFv+B/+gvP/AOC65/8AjdH/AAt/wP8A9Bef/wAF1z/8boAveNtV1fRLOC9054/I3bJg8e7B PQ/TqPyrjPAuq6v9vh0ixeNbd5DNMWjyVXA3HP4AfU1t6j8UfAOp6dPZT6tOY5kKn/iXXPHof9X1 B5rnvBXjbwZ4et7mS81WT7XM20bbC4YCMdORH36/lnkV20qtNUJJrX+vyOadOTqpp6HsdFcP/wAL f8D/APQXn/8ABdc//G6P+Fv+B/8AoLz/APguuf8A43XEdJ3FFcP/AMLf8D/9Bef/AMF1z/8AG6P+ Fv8Agf8A6C8//guuf/jdAHcUVw//AAt/wP8A9Bef/wAF1z/8bo/4W/4H/wCgvP8A+C65/wDjdAHc UVw//C3/AAP/ANBef/wXXP8A8bo/4W/4H/6C8/8A4Lrn/wCN0AdxRWfomuad4i0qLU9KuftFnKWC ybGTlSQRhgCOQeorQoAKKKKACiiigAooooAKKK4y6+K/guzvJ7WbV5POgkaKQJZXDgMpwRlUIOCO xoA7OiuH/wCFv+B/+gvP/wCC65/+N0f8Lf8AA/8A0F5//Bdc/wDxugDuKK4f/hb/AIH/AOgvP/4L rn/43R/wt/wP/wBBef8A8F1z/wDG6AO4orh/+Fv+B/8AoLz/APguuf8A43R/wt/wP/0F5/8AwXXP /wAboA7iuY8a6nq2jadFfaa0flK22YOm7Geh/Pj8RWd/wt/wP/0F5/8AwXXP/wAbqvf/ABT8BajY T2c+rTmKZCjf8S654z3/ANXV05KM05K6Jmm4tIwPBGrawNQi0mweNYJpjNMzR5KjA3H8gPxr1+vG /BXjXwZ4ejupbzVZPtUrbFK2FwwEY6ciPv1x7DPNdZ/wt/wP/wBBef8A8F1z/wDG63xc4zqe6ZYe Mow947iiuH/4W/4H/wCgvP8A+C65/wDjdH/C3/A//QXn/wDBdc//ABuuU3O4orh/+Fv+B/8AoLz/ APguuf8A43R/wt/wP/0F5/8AwXXP/wAboA7iiuH/AOFv+B/+gvP/AOC65/8AjdH/AAt/wP8A9Bef /wAF1z/8boA7iiuH/wCFv+B/+gvP/wCC65/+N10+h67pviTS01LSbn7RaOzKr7GTlTgghgCOfUUA aNFFFABRRRQAUUVyM3xN8JwXdxbNqFy0tvK0Mvl6fcyBXU4YbljIOCOxoA66iuO/4Wj4S/5/b3/w VXX/AMao/wCFo+Ev+f29/wDBVdf/ABqgDsaK47/haPhL/n9vf/BVdf8Axqj/AIWj4S/5/b3/AMFV 1/8AGqAOxorjv+Fo+Ev+f29/8FV1/wDGqP8AhaPhL/n9vf8AwVXX/wAaoA7GuX8bX+r6Tpsd/pkw SNG2zqYw3B6NyPXj8RVb/haPhL/n9vf/AAVXX/xqobv4j+Db6zmtZ7u9aKZCjD+yrrof+2VXTkoz TauiZpyi0mcr4L1PWW1SPTLCdY4Z5TNOfLVsDA3Hkegx9a9hryPwZ4n8K+Hlu5bq9u2uZHKIy6Xd H92Oh4j4z1x9K6v/AIWj4S/5/b3/AMFV1/8AGq3xdSM6nu7GWHi4w947GiuO/wCFo+Ev+f29/wDB Vdf/ABqj/haPhL/n9vf/AAVXX/xquU3Oxorjv+Fo+Ev+f29/8FV1/wDGqP8AhaPhL/n9vf8AwVXX /wAaoA7GiuO/4Wj4S/5/b3/wVXX/AMao/wCFo+Ev+f29/wDBVdf/ABqgDsaK47/haPhL/n9vf/BV df8Axqt/RNe03xHp32/Srgz23mNGWaJ4yGU4IKsAQQfagDSooooAKKKKAPPvhn/yJif9ft5/6USV 19ch8M/+RMT/AK/bz/0okrr61WxDCiiqq6jZtqb6atxGb1IhO0GfmCE4DfTIoEWqKxZfFugxMqtq URLFwoQF87GKN0B6MCKluPEmjWggNzqMEXnxiVN5x8h6Mf7q+5wOD6UDNWis6bX9Jt9QWwl1CBLp iq+WW6FvugnoCcjAPJyMdas/brU6idP89PtYiE5hz83lk7d30yMUAWKKzE8Q6RJqP2BNQgNzvMYQ N1cdVB6FuvGc8H0pln4m0fULtbW0vVllZmUBUbBK5zzjHGDQBrUVl33iLSdNuza3d4sc4QOUCMxC nIBOAfQ/lV+C6guYmlhkV41d4yw6BkYqw/AqR+FAEtFZMfijQ5lnaPVLZlgjaVyH/gX7zD+8o9Rk VcfUrKO8ltHuY1uIoftDxk4Kx5I3H2yDQBaorKi8S6LPdxWsepQNNLt2Lu6kjIXPTcQQdvX2rVoA KKKKBHOfCz/kTpP+wle/+j3rta4r4Wf8idJ/2Er3/wBHvXa1kaBRRRQAUUUUAFFFFABXBfD7/kAX n/YVvv8A0oeu9rgvh9/yALz/ALCt9/6UPVR3Ezq6Kp6jqtjpMMct9cLCkkgjQkE7mwTjj2BP4VFH r2kzLbtFqNs4uJjbxFZAd0oBJT/ewDxVkmjRWdd67pdgJPtN7FGY5fJZTktv2h9oA5J2sDx2NTpq NlJp39opdwmy2GQzhxsCjqc9MDFAFqisb/hK9C+yPc/2lD5SOsbdchm+6NuM84OOOcGrFtr2lXjx Jb30Mjyv5aop+bdtL4I6g7QTz6GgDRoqKO6gluJoI5FaWHb5ij+HIyM/hzUFhqthqgkNjdxXAiba 5Q5xnofcHseh7UAXKKojWdOMN9KLyLZYsUujn/VMACQ34EGpvt9r/aQ07z0+2GHz/Jz83l527vpn igCxRWNb+K9Cu0LQanA/yswHILBRltoIy2ACeM9KZH4x8PyxTSpqSGOD/WNsbC/MEx067mAx70Ab lFUtP1fT9VD/AGG7imMeC6qfmTOcZU8jODjPoaWPVrCWzjvI7qNreWUQpIOjOX2AD33cUAXKKy4/ EmjTXMtvHqVu0sQYsobsv3sHocYOcZxS6b4h0rV5fLsLsTsU8wYRgCvHOSMdxQBp1znwv/5Fq+/7 C97/AOjmro65z4X/APItX3/YXvf/AEc1TIcTtaKKKgoKKKKACvP/AIff8g7W/wDsOX3/AKONegV5 /wDD7/kHa3/2HL7/ANHGqjuJnXUVR1k3Y0LUDp4Jvfs0n2fHXzNp2/riuOgh8OTTaPFoSW013NJ5 d8iYaSSAo3mi5HU84+/zux71ZJ39FeWtpFla6L4imsbCyt7pNfhhglFuo2L51uQvGDtzzgEU7xUt 6l9djWJtNl+XTckxNHbhPtT58wMzcdc89KVwseoUV5hNa6dfvo1pp0HhW5d9QcyQ2aK9uR9nlI8x V78HH0FdD4UTydJ1mCRIra5S4fzrGFNsdsdigBB3VgN4PAO48A5FO4HXUV5To9zcaRcwapApkaTT bOyMZz80jwAwk/8AA12f9tKg0XQ3k1saemn6dqYtrS5j3akTxi+uF3DCt8x79PrSuFj12iuJ8P3V j4d1a90zVNYtVukgtIw1xOqNMRHgkBjk8/WuX8Otpa6PMZD4ZF5i8AyV+3ZJkA989P8AgNFwPXqK 8rtxP/ZOj6Oxfy9Kv7K538/Mks8Xkr7jEkq/WEVV8Otpa6PMZD4ZF5i8AyV+3ZJkA989P+A0XCx6 9RXnNjBJDdeFtDvojdWUgaW3eVd6tEbZw0T54O0kYz1Vl9DWZNpWl2fhrVZ1sNNgZfEPkmSaFVQQ i6T5HOP9XwMjpgUXA9ZorzCa106/fRrTToPCty76g5khs0V7cj7PKR5ir34OPoK6fwUnk2upQSJF bXKXjedYwptjtjtUAIO6sBvB4B3HgHIp3A6iuf8Ahx/yDdc/7D1//wCjjXQVz/w4/wCQbrn/AGHr /wD9HGpkOJ2VFFFQUFFFFAHn3wz/AORMT/r9vP8A0okrr65D4Z/8iYn/AF+3n/pRJXX1qtiGFcVr Wm6tF4quta0u2Z7hbeG3iJ6Or+arD6K5hc+y12tFAHltjoWoaFrMPkR6xb2cUV3CkljDFK5Budyb t6sMFRnOM1t6nFdSSG4it9ainmskiE8cUUv2ojd8k8TLtUgsTkbQQx5GMDt6KLBc4G4tNUjeVYtO ube+mMLPbRIk+n3LBUBZtwzGBt2nBU/KCN1TDTNaXUh4i2qJXvzutRARMLZsQgbtxBAULLt29Qfx 7iiiwHCQR6xb6XoujQadMlxYvDHOJLZJLeUIy5mEhPHAZhj5txHGaTwbHqOmpbWd3/bqbZ5swNbQ /ZgGkcg79m/GCD97r7cV3lFFgOcOk303i/ULxL+8srdra2VfJWIrKVaXIO9GPGR0I61nql5c6Dq/ h9bG9hubmW/EVw8WIf3ksroS+ehDD867OiiwHI3cD+JZNMs20i6s4Ld3N15yBAiGF4zEpB+bO8cr lcL9BWM2h63c6Rb3U9u41G+kOn3o6mO2dFid/wA4hIP9816PRRYDiJbO8g1NobCxvYS+orK9rJHH NZSIJATMHIzG2BvwCCHHAPWu3oooAKKKKBHOfCz/AJE6T/sJXv8A6Peu1rivhZ/yJ0n/AGEr3/0e 9drWRoFFFFABRRRQAUUUUAFcF8Pv+QBef9hW+/8ASh672uC+H3/IAvP+wrff+lD1UdxMt+KFnWTR LqG0nuVtdQEsqQJuYL5Mq5x9WH51g3OgXGu62Ly5sbi2s7q9D4YhZYwtqyrKcE7W37cdxtU131FX Yk8+hsNVjubi71WzvUulvnIv9NKs4At4E3iMhgySbCSMHaQBjuNqG0vZ/BE9vfab9onkMpNupW3k lUyEhjt+VZCDuPT5j25x09FFgPN73TNZ1Ka38htSe3W8s2F1d20SXUWyQlgDt+ZFBzllPJ4Jya0m 0PUozrEk/nX2pQyw3dleOFXz1jyUiwoAU8yIeBkSZ74HbUUWAwdPg1G38OXt3HCP7XvBLdrDMeFk Zf3cbf7qhEP+7WJ4Ls77SdWms0s706VJCCl3exhZQ6hQIsA8IoLbcLjkgHjJ7miiwHneseHtUGma /dadas1zdzzxS2+cfaIWxsYf7Skkj1BYdxV2XTNZOqN4jVE81NQ4tfIJma2GYSobfjBUtKF29SOa 7eiiwXOL8IeGbyDRdGbVL273WZMqWLpGqxvh15IXceHPU1DJo2oyeGNYtVhmjnn13z4yoG7y/tSN vGcjhQTyO1d1RRYDnNH029sfEt/JfzXF80sCC3vpFRcRKTmJggUBgzE5xyD/ALJrIs7K+g0yw8Pf 2fdedbaoJ3uCgEPlLcGUMHzg5GBjrk8gV3VFFgPPVsNREMVlZ2F/FGiT+bZXSRyQ22YnUGCbAYnc doAJ+VjkKK0fBf221s7CzvG1wtFZpE0d3bQpDGyqucMiBjjBAyT/AFrsaKLAFc58L/8AkWr7/sL3 v/o5q6Ouc+F//ItX3/YXvf8A0c1TIcTtaKKKgoKKKKACvP8A4ff8g7W/+w5ff+jjXoFef/D7/kHa 3/2HL7/0caqO4mddWXq+sf2VJZRR2M95PezGKOOFkU5CM5JLsB0Q961Kxde0/ULq60q804WzTWNw 0pS4kZFYNE6dVVufnz07VZJEfFVvs8pLG8bUPtBtvsGEEocIHyTu2hdpDbt2OR34o/4SqEKYWsLx dSEwg+wHZ5pYqXBB3bNu0E7t2OCOvFVF8O6gl+NcElqdXNw0rQ5YQlGjSMxhsbhxGrbtvUH5cHhH 8N6hLqq+IJHtf7WjmDRwBm8kQhGTy9+M5+dm37euBtwOUBoQ+JEa+srG40+8tbq6lkhCTKuFKR+Y TuViGBHQqTzwcEEVDN4vsoNbh0t4Zw8l09r5uBsVlWNgTznBMqKPc1FcaTrVzcWmqSyWb39pdNLB a72EKxNGYynmBdxJzu3FevGMc1Rm8H394811cXFul1P9olPllisMreT5RUkZIXyFJJxk9qAL114z t4dWuNMtrC6u7qG5itgsZRQ7PG78FmAwBGwOe/FTyeKUs7vT7XU9PurGS+d0TzGR1TbsALFGIAZn VR7nnFYF54GvZmhlK6fdt5kE88NwzLHLIFuPMPCnALz5HHatO28LGV7ZLzT9NtrSOG5hktbR2ZXE vl85Krz8jZ/DHsagT6h4t+xQzTRaReXUMN0LSR43iUCQuqDhnBIJYc0+TxTJHLLD/Yl+81vCJrqO NomaFTuxxvy5wpOFz1A68VTt/C2oR+G7jTZ76O4nk1GO6E75BZFmjf5uPvlU5xxk9qk8Q+HbzVru Vlt9NuEeMLBPPujnsmxglGRSWGecZXnvjoAb91fxWrWqMrNJdSiKJBwScFieewVWJ+nrWNYeL4Lm C2nu7C6sLe6tmuoZp2jZGjVQ5J2sSPlOeQPz4qze2c8eoaHcgyTrau0UzYyxDxld5A/2gufTcT0F c5p3gW4Fpa2d3b6ZZxRWT2c89gzebdq0RjIfKqAMnfzuOVHvTA3JPFJgsp7250bUoLZLWS6jkdUI kVE3kHaxKEjON2OmODxUtv4mh81YtStJtLLQG4V7uSLy2QMqn5lcgHLpwcfeHWqV5pXiPUtGn0u4 n0+CJrKW3LxFmNwzRlFLAr+7UE7iAWPA5xnMlx4QsI9LaKxsrcXTeXl3lkRvlZW+WRTuQ5GQR3Ay DQBrxavZz3VvDDKkqXMTSwTRuGSQKQGAIPUZH6+hq9XL2OlX8N7o8F05kNo9zdSSjJA37lSPdgbz iQknGTsyeoz1FABXnHhSLxYw146Rq2mW1p/bl9iO4smlfPnNk7hIP5V6PXJ+Af8Ajy13/sPX/wD6 Oak1cERzat4x0XWNDTUtS0m8tNQ1BbORIbF4mAZHbcGMh/uenevQq4Txh/yEvB//AGHov/RM1d3U NWZSCiiikM84+G11bxeDlSSeJGF7d5DOAf8Aj4krrvt1p/z9Qf8AfwVTm+Hvg64nkmm8NaW8sjF3 ZrZSWJOSTxTP+Fb+Cv8AoV9K/wDAZf8ACq5hWL/260/5+oP+/go+3Wn/AD9Qf9/BVD/hW/gr/oV9 K/8AAZf8KP8AhW/gr/oV9K/8Bl/wp8wuUv8A260/5+oP+/go+3Wn/P1B/wB/BVD/AIVv4K/6FfSv /AZf8KP+Fb+Cv+hX0r/wGX/CjmDlL/260/5+oP8Av4KPt1p/z9Qf9/BVD/hW/gr/AKFfSv8AwGX/ AAo/4Vv4K/6FfSv/AAGX/CjmDlL/ANutP+fqD/v4KPt1p/z9Qf8AfwVQ/wCFb+Cv+hX0r/wGX/Cj /hW/gr/oV9K/8Bl/wo5g5S/9utP+fqD/AL+Cj7daf8/UH/fwVQ/4Vv4K/wChX0r/AMBl/wAKP+Fb +Cv+hX0r/wABl/wo5g5S/wDbrT/n6g/7+Cj7daf8/UH/AH8FUP8AhW/gr/oV9K/8Bl/wo/4Vv4K/ 6FfSv/AZf8KOYOUv/brT/n6g/wC/go+3Wn/P1B/38FUP+Fb+Cv8AoV9K/wDAZf8ACj/hW/gr/oV9 K/8AAZf8KOYOUv8A260/5+oP+/go+3Wn/P1B/wB/BVD/AIVv4K/6FfSv/AZf8KP+Fb+Cv+hX0r/w GX/CjmDlKPwrIPg2Qggg6jeYI/67vXbVU03S7HR7FLLTbSG0tUJKwwoFUZOTwPc1bqCgooooAKKK KACiiigArz3wFdW8WhXiSTxIw1W+4ZwD/wAfD16FXN3Hw/8ACF1cy3E/hvTJJpXLyO1spLMTkk8e tNOwmrlv7daf8/UH/fwUfbrT/n6g/wC/gqh/wrfwV/0K+lf+Ay/4Uf8ACt/BX/Qr6V/4DL/hVcwu Uv8A260/5+oP+/go+3Wn/P1B/wB/BVD/AIVv4K/6FfSv/AZf8KP+Fb+Cv+hX0r/wGX/CjmDlL/26 0/5+oP8Av4KPt1p/z9Qf9/BVD/hW/gr/AKFfSv8AwGX/AAo/4Vv4K/6FfSv/AAGX/CjmDlL/ANut P+fqD/v4KPt1p/z9Qf8AfwVQ/wCFb+Cv+hX0r/wGX/Cj/hW/gr/oV9K/8Bl/wo5g5S/9utP+fqD/ AL+Cj7daf8/UH/fwVQ/4Vv4K/wChX0r/AMBl/wAKP+Fb+Cv+hX0r/wABl/wo5g5S/wDbrT/n6g/7 +Cj7daf8/UH/AH8FUP8AhW/gr/oV9K/8Bl/wo/4Vv4K/6FfSv/AZf8KOYOUv/brT/n6g/wC/go+3 Wn/P1B/38FUP+Fb+Cv8AoV9K/wDAZf8ACj/hW/gr/oV9K/8AAZf8KOYOUv8A260/5+oP+/go+3Wn /P1B/wB/BVD/AIVv4K/6FfSv/AZf8KP+Fb+Cv+hX0r/wGX/CjmDlL/260/5+oP8Av4KwvhaQ3hi9 IIIOrXpBHf8AfNV7/hW/gr/oV9K/8Bl/wrd0zSrDRrJbLTLOG0tUJKxQoFUEnJ4FS3caVi3RRRSG FFFFABXmvgXU7C1s9biuL62hk/ty+O2SVVP+uPYmvSq5y68A+Eb26lurnw3pks8zl5JGtlJdickn jqTTTsJq47+29J/6Cll/4EJ/jR/bek/9BSy/8CE/xrivG/gfwtY33hVbXw/p0K3GsJDMEgUeYnlS HafUZAP4Vv8A/CvfB3/QtaX/AOAy/wCFWnclqxrf23pP/QUsv/AhP8aP7b0n/oKWX/gQn+NZP/Cv fB3/AELWl/8AgMv+FH/CvfB3/QtaX/4DL/hT1A1v7b0n/oKWX/gQn+NH9t6T/wBBSy/8CE/xrJ/4 V74O/wCha0v/AMBl/wAKP+Fe+Dv+ha0v/wABl/wo1A1v7b0n/oKWX/gQn+NH9t6T/wBBSy/8CE/x rJ/4V74O/wCha0v/AMBl/wAKP+Fe+Dv+ha0v/wABl/wo1A1v7b0n/oKWX/gQn+NH9t6T/wBBSy/8 CE/xrJ/4V74O/wCha0v/AMBl/wAKP+Fe+Dv+ha0v/wABl/wo1A1v7b0n/oKWX/gQn+NH9t6T/wBB Sy/8CE/xrJ/4V74O/wCha0v/AMBl/wAKP+Fe+Dv+ha0v/wABl/wo1A1v7b0n/oKWX/gQn+NH9t6T /wBBSy/8CE/xrJ/4V74O/wCha0v/AMBl/wAKP+Fe+Dv+ha0v/wABl/wo1A1v7b0n/oKWX/gQn+NH 9t6T/wBBSy/8CE/xrJ/4V74O/wCha0v/AMBl/wAKP+Fe+Dv+ha0v/wABl/wo1A1v7b0n/oKWX/gQ n+NYHw+dJdO1qSNldG1y+ZWU5BBmOCDVn/hXvg7/AKFrS/8AwGX/AAra07S7DR7NbPTbOC0tlJIi hQKuT1OBQBz3jaaOC98JSzSJHGuvRFndgAB5M3Umuu/t7R/+gtY/+BCf41xXxCs7bUD4XtLyCOe3 l1yJZIpFyrDyZuCKvf8ACvfB3/QtaX/4DL/hUtXY07HYw3ltcRCWG4hkjbo6OCD+Ior5+t7eGzlv 7a3iWKCHUbyOONBhUUXEgAA9AKKgo+h6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigDiPiF/yEfB3/YcT/wBEy10tc/8AELTtYvItCu9G03+0Z9P1Nbp7cTpEWQRy LwzkDqwqh/b/AI4/6J1P/wCDi2/xqotIlo6+iuA0/wAd+J9VjnksvAU8qwTyW8h/tSBdsiHaw5xn B79Kt/8ACT+M/wDonk//AIN7b/GruKx2lFcX/wAJP4z/AOieT/8Ag3tv8aP+En8Z/wDRPJ//AAb2 3+NFwO0ori/+En8Z/wDRPJ//AAb23+NH/CT+M/8Aonk//g3tv8aLgdpRXF/8JP4z/wCieT/+De2/ xo/4Sfxn/wBE8n/8G9t/jRcDtKK4v/hJ/Gf/AETyf/wb23+NH/CT+M/+ieT/APg3tv8AGi4HaUVx f/CT+M/+ieT/APg3tv8AGj/hJ/Gf/RPJ/wDwb23+NFwO0ori/wDhJ/Gf/RPJ/wDwb23+NH/CT+M/ +ieT/wDg3tv8aLgdpRXF/wDCT+M/+ieT/wDg3tv8aP8AhJ/Gf/RPJ/8Awb23+NFwLHjb/j98Jf8A Yei/9EzV1lefXcvizxFrGgJd+EJNNtrLUku5bh9QglAVY3XG1Tn+MV6DQgPDz/x/6r/2FL3/ANKZ KKD/AMf+q/8AYUvf/SmSisiz6CooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigDz/AOH3/IO1v/sOX3/o4111cj8Pv+Qdrf8A2HL7/wBHGuurVbEMKKKKBBRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4ef8Aj/1X/sKXv/pTJRQf+P8A1X/sKXv/AKUyUVka H0FRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHzHruq alpHijW7bTtSvrWA6jcP5cNy6ruMhJOAao/8JP4g/wCg7qn/AIGSf40UUAH/AAk/iD/oO6p/4GSf 40f8JP4g/wCg7qn/AIGSf40UUXAP+En8Qf8AQd1T/wADJP8AGj/hJ/EH/Qd1T/wMk/xooouAf8JP 4g/6Duqf+Bkn+NH/AAk/iD/oO6p/4GSf40UUXAP+En8Qf9B3VP8AwMk/xo/4SfxB/wBB3VP/AAMk /wAaKKLgH/CT+IP+g7qn/gZJ/jR/wk/iD/oO6p/4GSf40UUXAP8AhJ/EH/Qd1T/wMk/xo/4SfxB/ 0HdU/wDAyT/Giii4B/wk/iD/AKDuqf8AgZJ/jR/wk/iD/oO6p/4GSf40UUXAP+En8Qf9B3VP/AyT /Gj/AISfxB/0HdU/8DJP8aKKLgd14U0+2uvDlvc3CNLPM8skkjyMWdjIxJJz1JNFFFAH/9k= ------_=_NextPart_001_01C75213.70BD4C5E Content-Type: image/jpeg; name="SPEERMINT Document Flow - v1-A.jpg" Content-Transfer-Encoding: base64 Content-Description: SPEERMINT Document Flow - v1-A.jpg Content-Disposition: attachment; filename="SPEERMINT Document Flow - v1-A.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAIpAkMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOWufHmm2+j6fqUdlqN0t/cyWsEFtAHlZ 0L7vl3dP3bd6daeM/tcd0/8AwjXiOH7PEZds1htMnIG1Pm5bnOPQGuDiDnwx4IEeoDT3/ty9xdFV YR/8fXOG49ufWvQdAFwt7IJ/FsesAxnECxQqVOR83yc+340AZcPxKtri+ls4/DPic3EIQyp/Z/MY bO0t83AOD+VTSfEO1+3Xtta6B4gvfsdw9tLLaWQkj3qcEA7v85qbRf8Ako3iv/r3sP8A0GWuf8K6 XrF7d+J5bDxFLp0I166UwpaRSAnK/NlgT6ce1AHocF0k1hHduj26PEJWWcbGjBGcMOxHf0rm4vH+ nSGCaTT9Wt9OuGVYtRmtdtu244Q5zuVSSMFgByK6HUHSHSbqSaCS6jSBy8UagvKApyoHGSemOOte XTahDofhODUNA8UxalpSpGIdD1JYpncEqBCrD5ww6AHdgigDsdR8d2thrd5pMWi63f3FoEMzWNoJ VXeu5ed3p7djSXPxB0mHTbW8gttRvGuLtrIWtvbEzpMqlmRkYgggKc1j2NtrFx8SvGP9l6la2YAs t/nWZnLHyTjGJFx39aoa7oEmgP4biOuMl7d67Nd3GpSRIAJGt5ckIflAwAAOaAOv07xel/8AajJo WuWKW0DTtJe2flKwXqqndy3t7Gs61+I0N7BBPb+FvFDwzqrxyjTvlZWGQc7umDmnoLhdM1YT+LY9 YBsZcQLFCpU7fvfJz7fjWN4UF2nhjRGPj6KGMWcB+zNBbfINi/ISRnjpnrQB0l540gt9bvdJt9H1 e+uLIRmdrSBGVd67l5Ljt7dqhufiJolp4ZvNdmS9WGynW2urZoCs8MhKgKUOP7yng4weK58abr1/ 8RfGJ0PX10p0Wz3BrNJxIxhO3O7oBg9PWsgLBL4Juzd+a2uSeIbJdZS5KMwmE8SgAKAPLKgFeOQf rQB6ZrHiTTtE8Nya9cO8lisaSKYV3M4YgLtHGc5FV4fF+mzzRxIlxufShqwyg/1JOMdfve3T3rz2 +3XWi3vhObcy+G7e9mm3kksixkWn5pJn6xVZ07/kJ2n/AGIif+hCgDutO8YaTqvg9/E9nI8unpBJ O4CjzFCAllIzwwweM1m6t8Q7PR082fQ9eltSkTi6hsw0R8wLtG7d1ywH14rh7+OTwn8N01a2jkfS dY0FIL+KNciC4a32xzgejEhG/wCAmuu8V/8AJKLf/dsP/R0NAHT6HrP9t2sk/wDZmo2Gx9nl38Hl O3AOQMnI56+1YTfEKz+33lrBoev3S2dw9tNcW1l5kYdT83IbP6ZrsK4HwbrGmab/AMJT9v1G0tca /dMfPnVOPl55NAHST+K9Fg8OJrxvQ+nyAeU6KS0rE4CKuNxYnjbjOaqWXjWyuNSt7C90/U9KmuiV tjqFv5azMBnarAkbsc7Tg+1cNZ/6Fpul+I7lWTQP+Elur4KUKiGCUOkUzDsoY7snoHzXT+NtTsNU tNL0jT7qC51S71C2ltBA4dogkiu03y5wqoG56c470Aal/wCMrS01K4sLTTtT1S4tsC5Gn2+9YSRk BmJAzjnAJPPSpYfF+k3On6Ze28kssOo3Ys4sJhklwxKupwVI2MCOuaxPBmpWOlTeIdM1G8gt9Qi1 a5uJVnZY2kjkbekgBPKlSBn/AGapaxremX+laHrdlbm20uHxGry3LIqRyLiRDPkfwMzD5jjPX3oA 7e81e2sdU03T5VkM2oPIkJUAqCiFznnjgGqXhnxXpviu2u5tO80C0uGtpVlUKwZe+ATx6H2NY+ra hZ6l4+8JQ2NzDdPC11PL5Dh/LTySoZsdAWYAetcZol/L4W0m31C0UmTWoruyiVUyGvUuZfIz9Q7j 6JQB3DfEfRfsOq3cUN9Mmm3iWUixRAtLI7BV8sbvmBJHPFW9J8X/ANq6jFZ/8I74gs/Mz+/vLLy4 lwCeW3HGcYHua861TTItHsPEWm20/kJbaposSzkD5SBAN5B4znk5r0HRxdLqcXneNotTTn/RRDAp fg90546/hQBe8N+KdL8VWtzPpsrH7NcPbzRyAB0dTjkZPB6g/wD16yLn4jWNvpNvqqaLrlzYzWxu jPb2gdY0BYHed2ARtJ+mK5XQIZfD3hqy8YWMUkiRS3UWq28S5M1v9pk/eAd3j6+67hWporB/2fXZ TkHRLgj/AL4egDq/D3iZPESyPHpOq2Uaqrq99beUsgbONpyc9P1FUdR8d2thrd5pMWi63f3FoEMz WNoJVXeu5ed3p7djW3of/Iv6b/16xf8AoAribTT9UvviV4vOna3JpoT7FvCW0cvmZhOPvg4xz09a AOqtPE1tcz6VbyWd9a3GpJM8UNzCEdBERu3jPGdwI65q5rOtWOgaa9/qE3lwqQoAUszsThVVRyzE 8ACuZ1eRdP8AG3g/+0L5GZLW9WS4m2xh22xckcAZ9BR4wv7RZ/DutNcRz6Rp+pZvHibekRaJ0SRi MgBWZc56bs0AaFl41srjUrewvdP1PSprolbY6hb+WszAZ2qwJG7HO04PtVhvFump4cvtbdZxb2Uk sU0Xl/vRJG5QqFzySw455yKxfG2p2GqWml6Rp91Bc6pd6hbS2ggcO0QSRXab5c4VUDc9Ocd6ybmN ovH8/hZflg1DUoNaK4BBiRCXB9jNAn/fdAHZHxVp39kaTqS+a8Oqyww2yqoLFpOmRnjAyT6YNXdW 1ez0Swa8vpCkYYIqqpZ5HJwqqo5ZiegFcD4fhdvG8XhxsLB4eubu8VByNkwUwA/RZpR/wCt3xw62 d54b1S6P/EtstSDXRP3Y90bokjegVmHJ6bs0AXdO8YWt7qkOnXOnanplzcBjbrf24QT7RlgpBIyB zg4OO1aejavba7pceoWiyCF3kQCQANlHZD0J7qaoXfiLRZNW0uwjaHULy5kLwrAUkMKhTmYnPyqM 4z1O7AzXM+BtH1S58JwzW/ia+tImuLrbBHb27Kn+kSdC0ZPvye9AHUJ4r01/CH/CTHzksDCZgGUb yM4AxnqTwBnuKd/wlOnf8Ie3ihTK2nram6IC/OFAyRjP3hgjGeorzjSZb7UPCfgjQNNghu5FjGpX kM03lBoYnwgY7W4aQqenOw0/UJ77TfCvj3w/qdvDayPZXGp2cMUxlVYZAQ6htq8CTJ6D79AHZP4+ tLZI5tR0bW9PtHZVN3c2o8pCxAUsVY7QSRyRio9W+Idro18bW50DxAc3H2aKVLIGOZyTgISw3Zxx 61zXiHTdZstO0/8A4SbxDLqXheeSJL9IbOOBoRlTGWIBJj3BQ2CCAa6Tx+QR4WIOQfEFp/7NQB0O j6p/bFgLv7BfWWWK+Tew+VJx325PFaFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFGbRdKubRLSfTLKW2jYukMkCsisc5IUjAPJ59z TbLQtH02cz2GlWNrMV2mSC3RGx6ZA6cVoUUARpbwRzyTpDGs0oAkkVQGcDpk98ZOPrSQ20Ft5nkQ Rxea5kk2IF3uerHHUn1qWigArPTQdGiv/t8ek2CXuS32hbZBJk9TuxmtCigCJLaCKeWeOCNJpseb IqAM+Bgbj1OB0zUV9pthqcSxX9lbXcatuVLiJZAD6gEdatUUAZ1r4f0Wxd3tNH0+3d0MbNFbIhZT 1BwOQfSoB4T8Ng5Hh/Ss/wDXlH/hWxRQBEltBFPLPHBGk02PNkVAGfAwNx6nA6ZqJ9NsJJpZXsrZ pZWRpHaJSXKcoSccle3p2q1RQBAbG0ZrhjawFrlQk5MYzKoGAG/vDBI59aaNOslYMtnbgiH7OCIl 4i/udPu+3SrNFAEDWVq9l9ia2ha02eX5BjBTbjG3b0xjtSyWltNbC2lt4ntxtAiZAV4II46cEDH0 qaigArMk8N6FNdNdS6Lpz3DPvaVrVC5brknGc+9adFACOiyIyOoZWGCpGQR6VSsNE0rSnd9O0yys 2k4dre3WMt9doGavUUAUb/RNK1V0fUdMsrxo+Ea4t1kK/TcDirTW8L25t3hjaArsMRUFSvTGOmPa pKKAKWn6Ppmkhxpum2dkJMbxbQLHu+u0DNSDTrFYoYhZ24jhk82JBEuI3yTuUY4OSeR6mrNFAFS4 0vTrtJ0uLC1mW4KmYSQqwkK/dLZHOMDGemKr23hzQ7K5S4tNG06CdOUlitUVl7cEDIrTooAihtbe 3t/s8MEUcPP7tEAXkkngcckn86aljaR2P2KO1gS02FPIWMCPaeo29Me1T0UANREjjVEUKigBVUYA A7CmJbQRTyzxwRpNNjzZFQBnwMDcepwOmalooAp3+k6bqgjGoafaXYjzs+0QrJtz1xkHHQflTrTT LCwtXtbOxtre3cktFDEqIxIwcgDB4q1RQBRsNE0rSnd9O0yys2k4dre3WMt9doGasm1tzdi7MERu VQxibYN4UnJXd1xnnFS0UARJbW8dzJcpBEs8oCyShAGcDoCepxk4+tPkjSWNo5EV0YFWVhkEHqCK dRQBRsNG0vSi507TbOzMn3zbwLHu+u0DNWoLeC1hENvDHDECSEjUKoJOTwPUkn8akooArW2m2Nm4 e1sreBxGIg0USqQgJIXgdMknHvRcafZXjl7mzt52MbRFpYlY7G6ryOh7irNFAEU1tBcW7288McsD rtaJ1DKw9CDwRTXsrWSOGN7aFkgZXiVowRGy/dKjsR2x0qeigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8 /sfF/i7VxdT6Z4f0t7SK6mt0afUHR28uQoSQIzjO31q1/bfj3/oXdE/8Gj//ABqoPh9/yALz/sK3 3/pQ9dXVqKJbOb/tvx7/ANC7on/g0f8A+NUf2349/wChd0T/AMGj/wDxqukop8qC7Ob/ALb8e/8A Qu6J/wCDR/8A41R/bfj3/oXdE/8ABo//AMarpKKOVBdnN/2349/6F3RP/Bo//wAao/tvx7/0Luif +DR//jVdJRRyoLs5v+2/Hv8A0Luif+DR/wD41R/bfj3/AKF3RP8AwaP/APGq6SijlQXZzf8Abfj3 /oXdE/8ABo//AMao/tvx7/0Luif+DR//AI1XSUUcqC7Ob/tvx7/0Luif+DR//jVH9t+Pf+hd0T/w aP8A/Gq6SijlQXZzf9t+Pf8AoXdE/wDBo/8A8ao/tvx7/wBC7on/AINH/wDjVdJRRyoLs5v+2/Hv /Qu6J/4NH/8AjVH9t+Pf+hd0T/waP/8AGq6SijlQXZzf9t+Pf+hd0T/waP8A/GqP7b8e/wDQu6J/ 4NH/APjVdJRRyoLs5v8Atvx7/wBC7on/AINH/wDjVH9t+Pf+hd0T/wAGj/8Axqukoo5UF2c3/bfj 3/oXdE/8Gj//ABqj+2/Hv/Qu6J/4NH/+NV0lFHKguyl4P1+58R6LJd3lpHa3EV1NayRRyGRQ0blS QSBkcelb9cb8Nf8AkA6l/wBhm+/9HtXZVmUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAcF8Pv+QBef9hW+/8ASh66uuU+H3/IAvP+wrff+lD11darYhhRRRQIKKKKACiiuZ1W /wBdt/E2n6baXenJBfLMyGWyd2j8sKcEiUBs7vQY96BnTUVx+h+JbzVdQEUmpafGftM0X2RbCXft jd1H7zzNuSFznb36VQ0PxrqGpJpjefY3c11H5lxa29nLG1smxm3l2cgqGAXoM7uOeKLgd/RXBweO b6TwppV61rb/ANp3V5FbzxAMEjRmUlwM5xsdCOerrVm28ZXY1O1W7t4BYSecs8yZBhIuGiRjk42n aAfQtnoDRcLHZ0Vydhr+ra1cfY7L7FbyxiWSeaaJpFCieSKNVQOpJPlMSd3GOnPFjRPEN3qOsSaf cwQxyW8LifyySDIsmzKk/wAJGDgjIzjPFFwOkormm1bWb46ldaWLEWtjM8KwzxuZLh4/v/OGAjGc qPlbpnviqa+LLjUrK41OwvtKsNPgZI1bUgR50jRrJjdvURj5wvRjkE49S4HY0VysniW/WcWSW9vL d36JLpUkZLQuhUbi7A8+X94kEblK45NdSM7RuIJ7kDFAC0UUUCCiiigAooooA5/4a/8AIB1L/sM3 3/o9q7KuN+Gv/IB1L/sM33/o9q7KsjQKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooA4L4ff8gC8/wCwrff+lD11dcp8Pv8AkAXn/YVvv/Sh66utVsQwooooEFFFFABVK50uC61a x1F2kE1msixhSNpDgA54/wBkYq7RQBiWHh6TTZALbWtRW2895vsxWAoS7l2GfK3YJY/xZ96I/C9l FYaVaxy3C/2YvlwTBl3lNu1lbjBDDGeOwIwQK26KBnOp4L0tAgV7kbIIIR846RMjBun3j5cYY9wg xirNr4Z0+1eQ/vJUkhlheOUgqyySNIwIx6sR9K2aKAOdtPCFtp0Fsmn6hfWssCPH56sjvIjOXKvv Ug4ZiQcZGTzycrH4Sitpo57HVNQs5gjJJJH5TtMWcuzPvjb5ixJ4x6dK6GiiwGFP4Xjm+0omp38E F5zdQxNGFmJXaxyUypYAZ2FfXg80svhmISzNYaheadFcKomhtfL2PhQoIDo207QoyuOAO/NblFAG dBolnay6a8AdF062a2gTdkBCEHOeSR5a9/WtGiigQUUUUAFFFFABRRRQBz/w1/5AOpf9hm+/9HtX ZVxvw1/5AOpf9hm+/wDR7V2VZGgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQBwXw+/5AF5/wBhW+/9KHrq647TvDnjfQ0urXTpvD0lpJeT3EbXHnb8SSM+Dt443Vc+y/EX+94W /wDJirUkS0dLRXNfZfiL/e8Lf+TFH2X4i/3vC3/kxT5kKzOlormvsvxF/veFv/Jij7L8Rf73hb/y Yo5kFmdLRXNfZfiL/e8Lf+TFH2X4i/3vC3/kxRzILM6Wiua+y/EX+94W/wDJij7L8Rf73hb/AMmK OZBZnS0VzX2X4i/3vC3/AJMUfZfiL/e8Lf8AkxRzILM6WiuK0jUfGuvWslzp39gLFHIYmFyswbcA CcbSRjBHvWh9l+Iv97wt/wCTFVNcknFii+ZXR0tFc19l+Iv97wt/5MUfZfiL/e8Lf+TFTzIdmdLR XNfZfiL/AHvC3/kxR9l+Iv8Ae8Lf+TFHMgszpaK5r7L8Rf73hb/yYo+y/EX+94W/8mKOZBZnS0Vz X2X4i/3vC3/kxR9l+Iv97wt/5MUcyCzOlormvsvxF/veFv8AyYo+y/EX+94W/wDJijmQWZL8Nf8A kA6l/wBhm+/9HtXZVzvgvQr7w/octtqMtvJdzXk91IbfdsBkcvgbueM10VZlhRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHGfDT/kX rv8A6/X/APQErs64z4af8i9d/wDX6/8A6AldnW+J/iyMqP8ADQUUUVgahRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUVyfjx9VtNLj1DTLuWEQtiZUPBU9D+B/nV04c8lG+5M5csbkHw0/5F67/AOv1/wD0 BK7OvHPA8mq3WsRWFpeTQ2m8z3AQ8YGM/ngCvY63xkOWq9dzLDy5oLyCiiiuU3CiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4sfEmyllnW1 0DxDdxwzSQGa3sd6MyMVbB3c8g07/hYcf/QqeKf/AAXf/ZVU+H3/ACALz/sK33/pQ9dXVqJNzn/+ Fhx/9Cp4p/8ABd/9lR/wsOP/AKFTxT/4Lv8A7Kugoo5Q5jn/APhYcf8A0Knin/wXf/ZUf8LDj/6F TxT/AOC7/wCyroKKOUOY5/8A4WHH/wBCp4p/8F3/ANlR/wALDj/6FTxT/wCC7/7Kugoo5Q5jn/8A hYcf/QqeKf8AwXf/AGVH/Cw4/wDoVPFP/gu/+yroKKOUOY5//hYcf/QqeKf/AAXf/ZVFcePLe7tp bebwl4oaKVCjqdO6gjB/irpaKOWwXPPfCeuQ+G7e5V/DPiaWeaTPmLp38A+6OW69Sfc10X/Cw4/+ hU8U/wDgu/8Asq6Cirm3OTlLcmKUVZHP/wDCw4/+hU8U/wDgu/8AsqP+Fhx/9Cp4p/8ABd/9lXQU VHKVzHP/APCw4/8AoVPFP/gu/wDsqP8AhYcf/QqeKf8AwXf/AGVdBRRyhzHP/wDCw4/+hU8U/wDg u/8AsqP+Fhx/9Cp4p/8ABd/9lXQUUcocxz//AAsOP/oVPFP/AILv/sqP+Fhx/wDQqeKf/Bd/9lXQ UUcocxz/APwsOP8A6FTxT/4Lv/sqP+Fhx/8AQqeKf/Bd/wDZV0FFHKHMM8O+ILTxLpX9oWcVxEgl khaO4j2SI6MVYEZOORWrXG/DX/kA6l/2Gb7/ANHtXZVBQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQBwXw+/5AF5/2Fb7/ANKHrq65T4ff8gC8/wCwrff+lD11darYhhRRRQIK KKKACiiigAorPGqofET6P5TeYtot15meMFyuMevFZKeLzcmJLLS5rmZoDcPEJUVgm9l+UMRvbKHg dOMkZFAzpqK52PxHfXl9dQWGiSzJbNGrvLOsTAvGsmCrDIIDgH3FaGp6s1lPb2lvaSXl7cK7xwoy qAq43MzE8AFlHc5YcegBpUVg33idNO0ZL+60+7jlMpia2ZRvG3Jdh2ZQis+R1A9Tin6h4ga11EWN nYSX04gFyyxyopMZLAbAx+c/KeBx0yRkUAbdFc7H4jvry+uoLDRJZktmjV3lnWJgXjWTBVhkEBwD 7ipIvEr3GozQW+mXE1tBdC0lnRlLI+QMmPO7Zk/e9OcY5oA3qKKKBBRRRQAUUUUAFFFFAHP/AA1/ 5AOpf9hm+/8AR7V2Vcb8Nf8AkA6l/wBhm+/9HtXZVkaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFAHBfD7/kAXn/YVvv8A0oeurrlPh9/yALz/ALCt9/6UPXV1qtiGFFFFAgoo ooAKKKKAMTUNLvhraavpb2v2g2xtZI7ncFK7tysCvcEnjHOeorMk8KXS6bbWJGmalBHBsKX1vjy5 SSWkQjJGc/dzxtGGHNddRRYZw0fgq6tr+a4Nvoupu4h23GpQF5gY4UjznB6lC3Xqa6PU9OupNStd U094Bd28UkJjnB2SRuVJGRypBRSDg9xjnI1qKLAc0fDV1qV7FPrt8blI45NkVszwBGkPIBQglQgC jJJO5iccAVX8LX/9m29hL/ZmpWsERhhjv4STCAzBHVgM7thQHpymQRmuvoosBw0fgq6tr+a4Nvou pu4h23GpQF5gY4UjznB6lC3Xqa0LzwzeXurR3EraeTHdLPHfiHbdRxq+7ygRwRj5ck/d6gnmupoo sAUUUUCCiiigAooooAKKKKAOf+Gv/IB1L/sM33/o9q7KuN+Gv/IB1L/sM33/AKPauyrI0CiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOC+H3/IAvP+wrff+lD11dcFoNz4h8O2 15YP4P1S6zqF1Mk0EsGx1eZmUjMgPQjtWr/wk+u/9CLrf/f23/8AjlaJqxLR1FFcv/wk+u/9CLrf /f23/wDjlH/CT67/ANCLrf8A39t//jlF0KzOoorl/wDhJ9d/6EXW/wDv7b//AByj/hJ9d/6EXW/+ /tv/APHKLoLM6iiuX/4SfXf+hF1v/v7b/wDxyj/hJ9d/6EXW/wDv7b//AByi6CzOoorl/wDhJ9d/ 6EXW/wDv7b//AByj/hJ9d/6EXW/+/tv/APHKLoLM6iiuX/4SfXf+hF1v/v7b/wDxyj/hJ9d/6EXW /wDv7b//AByi6CzOoorkLXxnqN9GZLHwlqd5GrFWeCWHareh3MpzgjtjnrU//CT67/0Iut/9/bf/ AOOVUlyuzEtVdHUUVy//AAk+u/8AQi63/wB/bf8A+OUf8JPrv/Qi63/39t//AI5U3Q7M6iiuX/4S fXf+hF1v/v7b/wDxyj/hJ9d/6EXW/wDv7b//AByi6CzOoorl/wDhJ9d/6EXW/wDv7b//AByj/hJ9 d/6EXW/+/tv/APHKLoLM6iiuX/4SfXf+hF1v/v7b/wDxyj/hJ9d/6EXW/wDv7b//AByi6CzOoorl /wDhJ9d/6EXW/wDv7b//AByj/hJ9d/6EXW/+/tv/APHKLoLMsfDX/kA6l/2Gb7/0e1dlXJ/D2xv7 Hw7cf2jZSWU9xqF1ciCRlLKskrMudpIzg+tdZWZYUUUUAFFFFABRRRQAUUUUAZGvatdaYthHZWcN 1dXt19mjSe4MKA+W8hJYI56Rn+HqRVb7Z4w/6AWh/wDg5m/+RaPEf/IV8L/9hU/+ktxXQUAc/wDb PGH/AEAtD/8ABzN/8i0fbPGH/QC0P/wczf8AyLXQUUAc/wDbPGH/AEAtD/8ABzN/8i0fbPGH/QC0 P/wczf8AyLXQUUAc/wDbPGH/AEAtD/8ABzN/8i0fbPGH/QC0P/wczf8AyLXQUUAc/wDbPGH/AEAt D/8ABzN/8i0fbPGH/QC0P/wczf8AyLXQUUAc/wDbPGH/AEAtD/8ABzN/8i0fbPGH/QC0P/wczf8A yLXQUUAc2db1+z1DTodU0fTYre9uPs4ktdSkmZG2MwO1oEBHyY6966Suf8Tf8f3hz/sKr/6JmroK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigDjPhp/yL13/wBfr/8AoCV2dcZ8NP8AkXrv/r9f/wBASuzrfE/x ZGVH+GgooorA1CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOf8R/8AIV8L/wDY VP8A6S3FcdqNzeJFq10krvB4lupdLiAziGVZBbxkegZBIxPqq+tdj4j/AOQr4X/7Cp/9JbitTU76 30nSrq/uVJgtYmmZVAJO0Z4zxn096APOtCOl6zr09zPD4ZupbnUZShnuwbtY0cogWLaf4UUgZ75q jDql7Da6RqCLO9noupS2S20TEG8uGMyceoGY1Hu7+ld+3iPRLaGzu9oWO5tGvEkWIZCAouCBzuJl VQoBJORT4fEAkme1fRdQgu/KNxDbSiENcKGAYoRIUyCy5DMpG4cUAYOs6Xd2/hzSdD2213f6nqCy XnnMVjmcbriTJCkhCYwoGPu4FFrBaaF4j0uG+tdM0eKO2urnFvNtheUmJAQzKuWCF8jHAIrotE10 66pmTSb21gBdVmuGhKsysUYDZIx6g84wcdelR/8ACRaTd3+qWLqX/stFmmd0BjOMk7TnkqRg9MHj 1wAcXBJey6h/bcPnF7JJ9XaI5/ewzTFEXHc/Z4GwPUipdIn0y+uJZPEksCWE8Dalaw3TgRSiWaUl yDwxWMQgA525yPvV1EfjC0EBuL3Tr7T1aze8jNysf72NBubBR2wQDnacHn2OHy+JdJXTdCvJIJCN TlhS0hMa+YjPjBIz8oXPzEdPfigDEvdD0jU7nwpbSWUlwJN8xa9XMwtkjYhHzzgPJGMHnjB5qnbR WhvlivpI7bQLu+u1EedkLmARwRRMem0iOVwvQ7e9dG3i5Gi0u4g0PU7mPUlH2V4zbjdlWfGGlBHy oW9MY5zxSt4jaW//ALJl8Man5jxec6O1qVEZbBZv33r+JwcZoA5NoJtR1MadoEpj09LyW/05gx8o tBCqkL28rzpU4HGQ2OKet7b69DJqMlxa2v26+NxBa6nlYbiOGJYmic9iJC7Y55XO0446i18WJPpa 6qdC1KDTBatci7lNuFEQTfnaJS/IAwNvcZxVqy1i31K4jsLvSrqzkmiNzFFeJGRIoIyRsZhkFlJB wfm+tAHPWxgfR/CclrHNFBJq7OkUkm8RgpPwjYGY/wC7/s4rvK5/xN/x/eHP+wqv/omaugoAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKK4/wCIWif2lon22Jc3Fnl+Opj/AIh+HX8DV04qc1Fu1yZycYtpXGfDT/kX rv8A6/X/APQErs68Y8C6J/a+vpJKuba1xLJnoT/Cv4nn6A17PXRjIKNV2e5lhpNw2CiiiuQ3Ciii gAooooAKKKKACiiigAooooAKKKKACiiigAoorJ1uCG5l0uC4iSWJ7vDRyKGVv3Uh5B68gU4q7sJu yNais3/hHtE/6A+n/wDgMn+FH/CPaJ/0B9P/APAZP8Kdo9/w/wCCL3ij4j/5Cvhf/sKn/wBJbiru vadNqunx2kRjCtcwPN5hIBiSVXdRgckhSPxrH1rStOsdZ8MS2lha28h1QqXihVCR9mn4yB7V1dJ2 6DV+pxUvgq7OpalcxXMIjEkM2mxtkiNlm8+RX4+60mMYzgfQCte3sNVudZGq6hHZwyW9vJBaW8Ez SLlypZncqvXYoAC8DPXPHL3nivU4nNvFdKn2LWM6jO6jEdq12I0jzjGWVic9QI271f0m/wBU17Vb sS39xZWcln9rjWNUV4Y5HxDywOG2QOxBHHmkdhhDN7T9NvtJ8H22m2j27ajBaLGskhPlmbby54zg tk9Oa5y98DajBZS2+makbnztNnsn+3OqcyOjFspHkn/Wkk5OWHvUOlX+swWvhm4a91PUp9UDXU1t mAbYBExAGQgHzSQ5y3birNtrWra3r02nxTzadbzXEyqWWIyxRwJCrqpG5SzSytyc4VT36AFnVvD2 s+IE/wBNFhaKkJt47eCZ5FKSMomYuUXnywyqoXGWOT6UZvBOqs3mx3Np5lvLdGyyzBYY2WXylwF4 O+VSx9IkxnFWLXV9STxPHoIv5LlItQIa4dEDtCLfe0bYUAkO8QyADhhnnJpmtXup3ema7dWWq3ds Yb9LKxECx4LkRx87lOR5rsP+A0AbsWgG3vtCETp9h0q1kiRD94vtREYcY4QSDr/FUd9o+oTz+ILm 3mgS4vLFLSyYkjyyqyEFuOPnkPTPAFM1b7Zo2gLBBqlzPeXN3BBHPchC6+ZIqtjaoHClj07VX1jU NUl1q+stKu0SS3tYAkRKAySu7M4UsCN4iiYgHI+YEjANAGZ/wh9+mhXthZaPpVlLNai2Ei6nNKHQ sodSDENoKBuRnnHGK6Ky0/U7nXE1XVltIWt4Hgt7e1laUDeVLszsq5PyKANvHPJzxy1xq+pk2tjZ 32tTvJeuJ4Rbwpe26JDuZCWARhukhIb0bqeK7LQY500xWuJNRaR3LY1HyvNQdMfu/lxxkfWgCl4m /wCP7w5/2FV/9EzV0Fc/4m/4/vDn/YVX/wBEzV0FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBwFl4w8W6x9qn0vw/pbWcV1Nbo0+oujt5blCSBGcZ2 +tWf7b8e/wDQu6J/4NH/APjVQfD7/kAXn/YVvv8A0oeurq1FEtnN/wBt+Pf+hd0T/wAGj/8Axqj+ 2/Hv/Qu6J/4NH/8AjVdJRT5UF2c3/bfj3/oXdE/8Gj//ABqj+2/Hv/Qu6J/4NH/+NV0lFHKguzm/ 7b8e/wDQu6J/4NH/APjVH9t+Pf8AoXdE/wDBo/8A8arpKKOVBdnN/wBt+Pf+hd0T/wAGj/8Axqj+ 2/Hv/Qu6J/4NH/8AjVdJRRyoLs5v+2/Hv/Qu6J/4NH/+NUjaz47dSreG9DKkYIOpvgj/AL9V0tFH KgucPocfjHQLaWC08OaMRJIZGZtUfPsP9V0A4rU/tvx7/wBC7on/AINH/wDjVdJRTl7zu9xLRWRz f9t+Pf8AoXdE/wDBo/8A8ao/tvx7/wBC7on/AINH/wDjVdJRS5UO7Ob/ALb8e/8AQu6J/wCDR/8A 41R/bfj3/oXdE/8ABo//AMarpKKOVBdnN/2349/6F3RP/Bo//wAao/tvx7/0Luif+DR//jVdJRRy oLs5v+2/Hv8A0Luif+DR/wD41R/bfj3/AKF3RP8AwaP/APGq6SijlQXZzf8Abfj3/oXdE/8ABo// AMao/tvx7/0Luif+DR//AI1XSUUcqC7KXhDX7jxHor3d3aR2lzFdTWssUcpkXdG5UkEgccelb9cb 8Nf+QDqX/YZvv/R7V2VZlBRRRQAUUUUAFZuqf8fmk/8AX5/7SkrSrN1T/j80n/r8/wDaUlVDcmWx pUUUVJRz/iP/AJCvhf8A7Cp/9Jbiugrn/Ef/ACFfC/8A2FT/AOktxXQUAZM3hnRri0v7WWwjeHUJ hPdKSf3rgggk5/2Rx0/M1afS7N3vXaHL3sYjuG3HLqAQB144J6Y61cooAzbpdK0hYL+5MVsttCba J2YgKjFfkUdySi8deBWdJH4YuNAe9MsaafBLLcNcxzPE0UjMxkO9SHViWYEZB5x7U/W1mt9e0jUj Zz3VpbpOjrApdopHCbJNo5PyiReMkb/rWXeWGp+IrmOI6XBp9n5hvLhLhN32l/uRBwpGWAUORk4x GMnBoAvX9v4V0yws4Lh0to8tNbvDNIkpz99w6Hec7vmbPOeaW5v/AAppttZ6dLNAsMYju4I4wzgj cWSTK5zlgTk5yQTzWAsOrQaZpbDT9TttZtdNjggubcLKkzgYaOZTwo3KDkkcNwwOaW3t9QtNdv22 a3YK3kW8Uel2cDW/lpEowDIjEAO0gGMDFAHTXureHdRMWm3d5A7TGNkQsVKu2Gj+YYKOeCvIbkY6 1OPDWkixNp9mYoZROZDM5lMo4D+aW37sADduzjjpWA8F5Jrz+Rpl3E1xfKb62nRZbOWNSAJw5Hyv sRCADncACvG6u1oAwpPB+iSiLNtOrxFyJUu5kkYvt3FnDBnJ2LyxP3R6VrWdnDYWkdtBv8qPO3zJ Gkbk55ZiSevc1PRQBz/ib/j+8Of9hVf/AETNXQVz/ib/AI/vDn/YVX/0TNXQUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHBfD7/kAXn/YVvv8A0oeu rrlPh9/yALz/ALCt9/6UPXV1qtiGFFFFAgooooAKKzPEepyaN4b1LU4VRpLW3eVRJ90lRnnHauUu vHF3badqE1tc6XqZtbVpmuLRXEcThkARxuP3g5Iw2flPGKLjO+orkLbxRcPARDqGk6pczTx20C2a Oio7BiTISzcBVY8D+HHen3fiLVNJvIdPv4rSS5mmt/KmgVlR43mWJ/lJJVl3r3IOR6YouB1lFc/q ev3Fjq72ccUTIpsQC2c/v55I279ggI9zWHo3je81CW1DTabcTT3RgawtlcTxIHKlydzDAADHgcfh RcDvKK890vxzeXuiy6g2paI06Wk1x9gjjfzQURiAT5h9BnjpnpWk3jC5/s7QnW2h+2Xl4ttdxnOI gsgikZef77JjPZgaLhY7CivPdL8c3l7osuoNqWiNOlpNcfYI4380FEYgE+YfQZ46Z6VsW3iS+1Aa fawR29tqE3mxXKTIziGVEDDADDKkEEHPIYUXA6qiuLh1/wARLpF3fzJYTLDdyWmILaX93slMbSsA zEqACdoGfcAE1u+HdVl1axllkmsrjy5TGs9k+UkG0HO0klCCSCpOeM96Lga9FFFAgooooAKKKKAO f+Gv/IB1L/sM33/o9q7KvPPBeu6bonhzUnvrlIydYvysY5dv379B1/pXcWeo215ZQXSSKqTRrIqu wBAIzg+/NQ4StzW0K5lexboqP7RB/wA9o/8AvoUfaIP+e0f/AH0KVmVckoqP7RB/z2j/AO+hR9og /wCe0f8A30KLMLklZuqf8fmk/wDX5/7Skq99og/57R/99Cs7UZY3vdJCSIx+2HgMD/yykqoLUmWx q0UUVBRz/iP/AJCvhf8A7Cp/9JbiugrE8R2Go3Z0q40yO1lnsb37QYrmdoldfKkjI3KjkH94D07V F9s8Yf8AQC0P/wAHM3/yLQB0FFc/9s8Yf9ALQ/8Awczf/ItH2zxh/wBALQ//AAczf/ItAHQUVz/2 zxh/0AtD/wDBzN/8i0fbPGH/AEAtD/8ABzN/8i0AdBRXP/bPGH/QC0P/AMHM3/yLR9s8Yf8AQC0P /wAHM3/yLQB0FFc/9s8Yf9ALQ/8Awczf/ItH2zxh/wBALQ//AAczf/ItAHQUVz/2zxh/0AtD/wDB zN/8i0fbPGH/AEAtD/8ABzN/8i0AHib/AI/vDn/YVX/0TNXQVy01r4l1TUtKa+0/SbS2s7v7S7wa jJM5xG64CmBB1cd+1dTQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAcF8Pv+QBef9hW+/wDSh66uuU+H3/IAvP8AsK33/pQ9dXWq2IYUUUUCCiiigCnq 2mxaxpF3pszukV1E0TMmNwBGMjNZut+FbTWmuWaee3a6t/s9x5OP3qg5UkEHlTnB9GI+m9RQMw28 P3FxEUvtavLpldZIHMcKNDIpyGXagye2DkEEjHNU18Hb57ma71e7uZplTbK4XfA6SCRTHxgDcAdp BHAHQYrqKKLAYKeGFeSSe91C5urqSa3kMpVEAELl0QKBgDJbPc7jz0pbfwtZ21hYW0U0yvYXDTwT 5G8bnZmUnH3WDFSPTHcA1u0UAcvaeDpLTR20ga7fPpzQSQeQ0UP3XBH3tmeN2evarJ8JWP22a6Es 4aWa3n25G1WiKngY43bV3euK36KLAcvaeDpLTR20ga7fPpzQSQeQ0UP3XBH3tmeN2evatFvDtkde tNYUyJc28Jh+VvlkXGAWHcjnB9zWvRRYDIXQEisJLa3vbq3druS8WaNgGV3dnIwRgr8xGCDx781N pelf2e9zPLcyXV1dOHmmdVXOFCgAKAAAB7n3rRooAKKKKBBRRRQAUUUUAcL4S8LaZ4g0DUmu42W4 GsXyrPGcMB578ehH1ruLLw/ptrY29u9lazNFEqGRoFy5Axk/WsH4a/8AIB1L/sM33/o9q7Kl7Sdu W+hXJG97FL+xtL/6Btn/AN+F/wAKP7G0v/oG2f8A34X/AAq7RU88u4+Vdil/Y2l/9A2z/wC/C/4U f2Npf/QNs/8Avwv+FXaKOeXcOVdil/Y2l/8AQNs/+/C/4U+HTLC3lEsNjbRyL0dIlBH4gVaoo5pd wsgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcF8Pv+QBef9hW+/8ASh66uuHsPD/xC0L7Xa6Z /wAIxLZyXk9xE1zLcCTEkjPhgqYz83arfkfFH/nl4P8A+/1z/wDEVakiWjraK5LyPij/AM8vB/8A 3+uf/iKPI+KP/PLwf/3+uf8A4inzIVmdbRXJeR8Uf+eXg/8A7/XP/wARR5HxR/55eD/+/wBc/wDx FHMgszraK5LyPij/AM8vB/8A3+uf/iKPI+KP/PLwf/3+uf8A4ijmQWZ1tFcl5HxR/wCeXg//AL/X P/xFHkfFH/nl4P8A+/1z/wDEUcyCzOtorkvI+KP/ADy8H/8Af65/+Io8j4o/88vB/wD3+uf/AIij mQWZ1tFcLpmqePdet3udJh8N+RG5if7W06NvABOAoYYwR3z1q75HxR/55eD/APv9c/8AxFVNcknF ii+ZXR1tFcl5HxR/55eD/wDv9c//ABFHkfFH/nl4P/7/AFz/APEVPMh2Z1tFcl5HxR/55eD/APv9 c/8AxFHkfFH/AJ5eD/8Av9c//EUcyCzOtorkvI+KP/PLwf8A9/rn/wCIo8j4o/8APLwf/wB/rn/4 ijmQWZ1tFcl5HxR/55eD/wDv9c//ABFHkfFH/nl4P/7/AFz/APEUcyCzOtorkvI+KP8Azy8H/wDf 65/+Io8j4o/88vB//f65/wDiKOZBZl34a/8AIB1L/sM33/o9q7Kub8D6HqOgaBJbaq9q97PeT3Un 2VmMYMkhfALAHv3FdJWZYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQBxnw0/5F67/6/X/9ASuzrjPhp/yL13/1+v8A+gJXZ1vif4sj Kj/DQUUUVgahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVTvdVsNNKC9vIbcvkr5jhc464q5XOeNtF/t jw9L5aZubb97FjqcdR+I/XFXTUZTSlsTNtRbRhfD3V9Os9GuLe5vYIppLxiiO4BYFUAwPqK9AryP 4d6J/aGtG/lXMFnhhnoZD938uv5V65XRjYxjVdjLDNuGoUUUVyG4UUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHl+lSeOPEaXl/beMILCBb6 4gjt/wCyY5dixysg+YsCeFq//Yvj7/of4P8AwRx//F1J8Pv+QBef9hW+/wDSh66urSViW2ch/Yvj 7/of4P8AwRx//F0f2L4+/wCh/g/8Ecf/AMXXX0U+VCuzkP7F8ff9D/B/4I4//i6P7F8ff9D/AAf+ COP/AOLrr6KOVBdnIf2L4+/6H+D/AMEcf/xdH9i+Pv8Aof4P/BHH/wDF119FHKguzkP7F8ff9D/B /wCCOP8A+Lo/sXx9/wBD/B/4I4//AIuuvoo5UF2ch/Yvj7/of4P/AARx/wDxdH9i+Pv+h/g/8Ecf /wAXXX0UcqC7OHsfCnjLTIWhsvG9rBGzmRlXQ4+WPU8yVZ/sXx9/0P8AB/4I4/8A4uuvoptXd2C0 0RyH9i+Pv+h/g/8ABHH/APF0f2L4+/6H+D/wRx//ABddfRS5UF2ch/Yvj7/of4P/AARx/wDxdH9i +Pv+h/g/8Ecf/wAXXX0UcqC7OQ/sXx9/0P8AB/4I4/8A4uj+xfH3/Q/wf+COP/4uuvoo5UF2ch/Y vj7/AKH+D/wRx/8AxdH9i+Pv+h/g/wDBHH/8XXX0UcqC7OQ/sXx9/wBD/B/4I4//AIuj+xfH3/Q/ wf8Agjj/APi66+ijlQXZkeAdU1LVfD0z6tcpdXdvfXFq06RCMSCOQqDtHA6V1Ncb8Nf+QDqX/YZv v/R7V2VZlhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHBfD7/kAXn/AGFb 7/0oeurrlPh9/wAgC8/7Ct9/6UPXV1qtiGFFFFAgooooAKKK87k8X3bQa7Ot2wjuLG5uNM/clREY VYDBIw29dsg69GoGeiUV5wfEer6dFeyIdTk+yac9xLHqiwA7jt8t4/LGWUHfuycAehrT8TS6p4b8 P311F4hmuLj7MzpFPHDvLhk+aPCrwASCDkcr07lwsdpRXEa34j1aK8dEtLvTVWxeULceS29vOhXI 2M/QMw5x1qwINQj8W31v/b2ovb29lFdrEwhwWZ5QVOI87cIvv70XA6+ivN9M1rV7XwedcnbXJp10 wXGbwW32d3KA5AT58ZOe3AOa6pdNvIphay+J7tjcRsdrrCsu5Sp3R4QYGMgghvvDp3Lgb1FcDoV9 qv8AZugXk+rXdy99qclvMsqx7QiLcAAbVBGdik89R2pdc1fVRr7WNvcX/lHVBD5disXm7PsfmYBk GMb+Tmi4He0V5o+u61cnTVS51byLq+uI1SNLdbwokQJVxgIpEgfjg7cZ5rvdHEo0uHzzemQ5z9t8 vzRyfveX8v0x2xRcC9RRRQIKKKKACiiigDn/AIa/8gHUv+wzff8Ao9q7KuN+Gv8AyAdS/wCwzff+ j2rsqyNAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDgvh9/wAgC8/7Ct9/ 6UPXV1ynw+/5AF5/2Fb7/wBKHrq61WxDCiiigQUUUUAMljWaF4nBKOpVgCRwfcdKo3WhaZe6bDp9 xaq1pAuyOMMVCjYY8DBz9xmH41o0UDKc+l2NzNBLNbI7wo8SFv7jDDKR3BAHByOBVH/hE9F8mWJ7 RpEliEBEs8j7Y8g7FLMdq5A4XA4HpW1RQBSvdJsdQk33VuJG8sxZ3EfKWViOD6op/CpTY2xvJbsx Dz5Ylgd8nlAWIH5s351YooAxrLwrpGn7RbwT+WsZiEUl3LJHsI27djMVxjjGKsWGhadps/n20LiX y/KVpJnkKJnOxdxO1eBwMDgegrRooAzf7B0z+y100WoFqjmRFV2BR9xbcrA7gcknIPei10HTLMwm G2O+GZp1keRncyMpQszMSWJU4ySeMegrSooAx7vwto99ctcTWriZpPOLxTyRHeVClvlYYJUAH1xz V+xsYNOthb2/m+WCSPNmeU8+7En9as0UAFFFFAgooooAKKKKAOf+Gv8AyAdS/wCwzff+j2rsq434 a/8AIB1L/sM33/o9q7KsjQKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4L 4ff8gC8/7Ct9/wClD11dcknw51O0luRpvjTUrK2muJbgQJbwsELuWIBIz1Jp/wDwgniL/ooOq/8A gJB/8TVqRNjqqK5X/hBPEX/RQdV/8BIP/iaP+EE8Rf8ARQdV/wDASD/4mjmQcp1VFcr/AMIJ4i/6 KDqv/gJB/wDE0f8ACCeIv+ig6r/4CQf/ABNHMg5TqqK5X/hBPEX/AEUHVf8AwEg/+Jo/4QTxF/0U HVf/AAEg/wDiaOZBynVUVyv/AAgniL/ooOq/+AkH/wATR/wgniL/AKKDqv8A4CQf/E0cyDlOqorl f+EE8Rf9FB1X/wABIP8A4mj/AIQTxF/0UHVf/ASD/wCJo5kHKdVRXnvhvRtf8TadJex+MNRsAkxi 8pI45QSADnLgn+LGOnFbH/CCeIv+ig6r/wCAkH/xNXUXJJxfQmD5oqSOqorlf+EE8Rf9FB1X/wAB IP8A4mj/AIQTxF/0UHVf/ASD/wCJqOZFcp1VFcr/AMIJ4i/6KDqv/gJB/wDE0f8ACCeIv+ig6r/4 CQf/ABNHMg5TqqK5X/hBPEX/AEUHVf8AwEg/+Jo/4QTxF/0UHVf/AAEg/wDiaOZBynVUVyv/AAgn iL/ooOq/+AkH/wATR/wgniL/AKKDqv8A4CQf/E0cyDlOqorlf+EE8Rf9FB1X/wABIP8A4mj/AIQT xF/0UHVf/ASD/wCJo5kHKWvhr/yAdS/7DN9/6PauyrE8K+HR4Y0Y2H22W9d55biSeVQrO8jFmOBw OTW3UFBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFAHFfDD/AJFq5/6/G/8AQErta4r4Yf8AItXP/X43/oCV2tb4r+NIyofw0FFFFYGo UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV5n4ds/EXiWwkv18SXFviZkKcnsD2Ix1r0yuM+GX /IsTf9fT/wDoK100ZONOUlvp+pjUXNOKfmN/4RPxJ/0Nlx+Tf/FUf8In4k/6Gy4/Jv8A4qu1oqfr NTy+5D9jH+mziv8AhE/En/Q2XH5N/wDFUf8ACJ+JP+hsuPyb/wCKrtaKPrNTy+5B7GP9NnFf8In4 k/6Gy4/Jv/iqP+ET8Sf9DZcfk3/xVdrRR9ZqeX3IPYx/ps4r/hE/En/Q2XH5N/8AFUf8In4k/wCh suPyb/4qu1oo+s1PL7kHsY/02cV/wifiT/obLj8m/wDiqP8AhE/En/Q2XH5N/wDFV2tFH1mp5fcg 9jH+mziv+ET8Sf8AQ2XH5N/8VR/wifiT/obLj8m/+KrtaKPrNTy+5B7GP9NnFf8ACJ+JP+hsuPyb /wCKo/4RPxJ/0Nlx+Tf/ABVdrRR9ZqeX3IPYx/ps4r/hE/En/Q2XH5N/8VR/wifiT/obLj8m/wDi q7Wij6zU8vuQexj/AE2cV/wifiT/AKGy4/Jv/iqP+ET8Sf8AQ2XH5N/8VXa0UfWanl9yD2Mf6bOK /wCET8Sf9DZcfk3/AMVR/wAIn4k/6Gy4/Jv/AIqu1oo+s1PL7kHsY/02cV/wifiT/obLj8m/+Ko/ 4RPxJ/0Nlx+Tf/FV2tFH1mp5fcg9jH+mziv+ET8Sf9DZcfk3/wAVR/wifiT/AKGy4/Jv/iq7Wij6 zU8vuQexj/TZxX/CJ+JP+hsuPyb/AOKo/wCET8Sf9DZcfk3/AMVXa0UfWanl9yD2Mf6bPKfB+hav qOlTy2GuS2MSXDIY0BwWCr83BHqPyrof+ET8Sf8AQ2XH5N/8VTvhp/yL13/1+v8A+gJXZ1tiK841 Glb7kZ0qUXBN/mcV/wAIn4k/6Gy4/Jv/AIqj/hE/En/Q2XH5N/8AFV2tFY/Wanl9yNPYx/ps4r/h E/En/Q2XH5N/8VR/wifiT/obLj8m/wDiq7Wij6zU8vuQexj/AE2cV/wifiT/AKGy4/Jv/iqP+ET8 Sf8AQ2XH5N/8VXa0UfWanl9yD2Mf6bOK/wCET8Sf9DZcfk3/AMVR/wAIn4k/6Gy4/Jv/AIqu1oo+ s1PL7kHsY/02cV/wifiT/obLj8m/+Ko/4RPxJ/0Nlx+Tf/FV2tFH1mp5fcg9jH+mziv+ET8Sf9DZ cfk3/wAVR/wifiT/AKGy4/Jv/iq7Wij6zU8vuQexj/TZxX/CJ+JP+hsuPyb/AOKo/wCET8Sf9DZc fk3/AMVXa0UfWanl9yD2Mf6bOK/4RPxJ/wBDZcfk3/xVH/CJ+JP+hsuPyb/4qu1oo+s1PL7kHsY/ 02cV/wAIn4k/6Gy4/Jv/AIqj/hE/En/Q2XH5N/8AFV2tFH1mp5fcg9jH+mziv+ET8Sf9DZcfk3/x VH/CJ+JP+hsuPyb/AOKrtaKPrNTy+5B7GP8ATZxX/CJ+JP8AobLj8m/+Ko/4RPxJ/wBDZcfk3/xV drRR9ZqeX3IPYx/ps5PwBf3l9o10b25e4kiumjV3OTjav+JrrK4z4b/8gjUP+v1//QVrs6WISVWV h0XeCCiiisTQKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK4z4Zf8AIsTf9fT/ APoK12dcZ8Mv+RYm/wCvp/8A0Fa3h/Bn8v1MpfxI/P8AQ7OiiisDUKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4z4af8AIvXf/X6//oCV2dcZ8NP+Reu/+v1/ /QErs63xP8WRlR/hoKKKKwNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo A4z4b/8AII1D/r9f/wBBWuzrjPhv/wAgjUP+v1//AEFa7Ot8T/FkZUf4aCiiisDUKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAK4z4Zf8AIsTf9fT/APoK12dcZ8Mv+RYm/wCvp/8A 0Fa3h/Bn8v1MpfxI/P8AQ7OiiisDUKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooA4z4af8AIvXf/X6//oCV2dcZ8NP+Reu/+v1//QErs63xP8WRlR/hoKKKKwNQ ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4z4b/8AII1D/r9f/wBBWuzr jPhv/wAgjUP+v1//AEFa7Ot8T/FkZUf4aCiiisDUKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAK4z4Zf8AIsTf9fT/APoK074hadcTaQuoWksqSWp/eBGI3IevT0PP0zXGeA9OuNT1 1FEsq2lsfOlVWIBPYfif0BrupUk8PKV/6RzTqNVUrHslFFFcJ0hRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFcl8QNOnuND+3Wkskc1odzBGI3IevT04P51dOCnJR btcmcuWLZD8NP+Reu/8Ar9f/ANASuzrxnwNp1xqmvRoJZVtID50wVyAfQficfgDXs1dGMgo1XruZ YeV4bBRRRXIbhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRXJfEDSZL7Q/tl uWE9nlztONyfxfl1/A1dOKnJRbtcmcnGLaRD8N/+QRqH/X6//oK12deLeCNJk1fX41Yt9lg/fTYP Bx0H4n9M17TXRjIKNV67mWHk5Q2CiiiuQ3CiiigAooooAKKKKACiiigAooooA86s/iB4o1aOW60n wPHc2QnlijmfV0jL7HKElSnHKmrH/CW+Ov8Aon0H/g9j/wDjdR/DP/kTE/6/bz/0okrr6tRRNzlP +Et8df8ARPoP/B7H/wDG6P8AhLfHX/RPoP8Awex//G66uijlQXOU/wCEt8df9E+g/wDB7H/8bo/4 S3x1/wBE+g/8Hsf/AMbrq6KOVBc5T/hLfHX/AET6D/wex/8Axuj/AIS3x1/0T6D/AMHsf/xuuroo 5UFzkpfFPjeaJ4pPh5btG6lWU65Hgg9R/q6yvD134w8OWclvb+AopTJIXaRtajBPoPuHp09+TxnF ehUVSuouKejJ0bucp/wlvjr/AKJ9B/4PY/8A43R/wlvjr/on0H/g9j/+N11dFTyoq5yn/CW+Ov8A on0H/g9j/wDjdH/CW+Ov+ifQf+D2P/43XV0UcqC5yn/CW+Ov+ifQf+D2P/43R/wlvjr/AKJ9B/4P Y/8A43XV0UcqC5yn/CW+Ov8Aon0H/g9j/wDjdH/CW+Ov+ifQf+D2P/43XV0UcqC5T8H+In8U+Ho9 TlsfsUpllhkt/NEmxkcofmwM9PSt6uK+Fn/InSf9hK9/9HvXa1BQUUUUAFFFFABRRRQAV57B498U ajJdSaT4Jju7OG5lt0nfV0iLmNyhO0pxyK9Crgvh9/yALz/sK33/AKUPTSuJsP8AhLfHX/RPoP8A wex//G6P+Et8df8ARPoP/B7H/wDG66uiq5UK5yn/AAlvjr/on0H/AIPY/wD43R/wlvjr/on0H/g9 j/8AjddXRRyoLnKf8Jb46/6J9B/4PY//AI3R/wAJb46/6J9B/wCD2P8A+N11dFHKgucp/wAJb46/ 6J9B/wCD2P8A+N02TxT43ljaOT4eW7IwKsp1yPBB7f6uutop8qC5554euvGHhy2mhtvAUUplk3s7 a3GDjsv3D09e/XjOK2P+Et8df9E+g/8AB7H/APG66uinK8nzS3FH3VZHKf8ACW+Ov+ifQf8Ag9j/ APjdH/CW+Ov+ifQf+D2P/wCN11dFTyodzlP+Et8df9E+g/8AB7H/APG6P+Et8df9E+g/8Hsf/wAb rq6KOVBc5T/hLfHX/RPoP/B7H/8AG6P+Et8df9E+g/8AB7H/APG66uijlQXOU/4S3x1/0T6D/wAH sf8A8brf8H+I5PFGhf2hNYfYZknlt5bfzRLtaNypwwAz09KuVznwv/5Fq+/7C97/AOjmpSVhp3O1 oooqRhRRRQAVwNr458SapNfnSvCNtcWtreTWglk1YRlzG5Unb5RxnHqa76vP/h9/yDtb/wCw5ff+ jjTSuJlv/hJfGv8A0JVl/wCDsf8Axmj/AISXxr/0JVl/4Ox/8ZromYKpZiAoGST0FZFv4p0i6bbD PM25GkiP2WUCdVGT5RK4l45wmSR0quVCuyp/wkvjX/oSrL/wdj/4zR/wkvjX/oSrL/wdj/4zU0Pj DRp/NKS3arFKsMjSWM6KkjMqhCWQANl146856Vb1DXtN0t3ju53WRBGxRIXkY+Y5RMBQSSWBGBzR yoLszv8AhJfGv/QlWX/g7H/xmj/hJfGv/QlWX/g7H/xmrT+KdMijjaRdQQyyeVGjabcB3baWwqeX uPCk5AxxV2y1Wz1C2lnt5GKQuUlDxtGyMACQysAwOCDyOhFHKguzI/4SXxr/ANCVZf8Ag7H/AMZp G8R+NHUq3gixKkYIOtjBH/fmtKw1/S9Tuza2d0JJxAlzs2MP3bjKtyOeCPpnmqSeM9CmEZguZ7gS RtKpt7OaX5FdkLHahwNyMMn0o5UF2YmgSeK/D0FxFbeDLN/OlMhZtaAIHZf9V0H+JrX/AOEl8a/9 CVZf+Dsf/Ga17HVbHUy/2K4WYKiOSoONrjcpB6HI9Ko2/ivSbtS8DXjxLvzN9gnEXyZ3fPs28bSO vUYqpe8+aT1EvdVkVv8AhJfGv/QlWX/g7H/xmj/hJfGv/QlWX/g7H/xmr6+ItJbTrG/F4ptb6VIb Z9rfvHc4VcYyDnPXpg5xUNv4r0m7UvA148S78zfYJxF8md3z7NvG0jr1GKnlQ7srf8JL41/6Eqy/ 8HY/+M0f8JL41/6Eqy/8HY/+M1oDxBpj2NneR3JlgvFLW5hieQyYUsQFUE5wp4xnjHXiqaeM9Eki llWS92RSCJidOuB+8LBNgynL7mA2jn2o5UF2R/8ACS+Nf+hKsv8Awdj/AOM0f8JL41/6Eqy/8HY/ +M1afxTpkUcbSLqCGWTyo0bTbgO7bS2FTy9x4UnIGOKvafqVrqcUklq7MI3McivG0bIwAOGVgCDg g8joRRyoLsx/+El8a/8AQlWX/g7H/wAZrX8JeIZvEulT3VzYCxuLe7mtJYFm80B422nDbRkZHpVy uf8Ahx/yDdc/7D1//wCjjSkrDTudlRRRUjCiiigDz74Z/wDImJ/1+3n/AKUSV19ch8M/+RMT/r9v P/SiSuvrVbEMKx18QQnxa/h8wusq2guVmJG1ssRtHfPf6Z9K2K5fWvCs2qajdXkN4LeWVYURwvKA CVJPzSZsehAPagCvYeOm1maCLStIluDNHNKu+ZY/kSXy88+vBx71oXXiSe3vBZx6TPcXUdsl1cQx ypuRWLDCAkeYco3TjpzzWHN4DlGqreLb6PeRKLhVgvrcuiCSbzAVGOCBxWhqPhq9v7aKCS30WaFY BEkEtsdtmw43QkDOMY+XjG3gjpS1AuHxOX1Ge3t9Lup4rZ447h0KiRC6qwPlE7ioDjJx64BxVpde gbxK2iiN9yxb/O/gL8Ex/wC8FZW+hrFvfCV9dmOKW5s7koIxDqU8OLy3CgZ2uv3iSCwJIxnkNU3/ AAiDbUvPtLHVRfm8aQzSGJsthl2E4x5JMecZxijUC7aeIp7xre4i0e7bTbllWG7UqSQ33XKA7gh6 564IJAGcN0PxBe62sdxHpDRWMjyIJ2uFJGxmXO3r1Ws4+E9QaLTbB7q1+x6c8f2e5UOs4iRlITaD tzhQpbuMnaDTPDvhG40K5hY2OhOySyObxbci5IdmJ+bHXDY69KANi71u9TWJ9OsNJa7aCKOWRzcL GBvLAAZ6/cNWYdatm0i61ObMNvayXCyFucCGR0Y/jsJ/GqsnhjT7vxFc6rf2VndmSGGOHzoFdoih ckgkcZ3Dp6VUTQdTks7/AEi5kszpd5JdFnj3iZVmd3GM/LkFx+VMB114rl0+2ae/0W7tkeKSS33O hMhRGk2MATsYqrEDkcHnPBnuPFdlbaheWzI7R2ti16064KsFAZlHuFdG+jUiaVqt9d2LaxPZvDYu ZFFujAzuUZAzAnCjDN8o3ZOOeMVlp4HlGiafZPeq80N2JLiUg/v4AvlmP2zGqA+60tQNCy8UzXtw Vj0e5MMc6207q6M0MhwDlAd20E8t6ZOMc10dcteeGby91aO4lbTyY7pZ478Q7bqONX3eUCOCMfLk n7vUE811NMAooooEc58LP+ROk/7CV7/6Peu1rivhZ/yJ0n/YSvf/AEe9drWRoFFFFABRRRQAUUUU AFcF8Pv+QBef9hW+/wDSh672uC+H3/IAvP8AsK33/pQ9VHcTNfWtWk0pbJYbNrqa7uRbxxiQJzsd 85PshrLufG1pYyxRXtlc20n2sWs6vtPkgxlxISpIKYHUHjnOMGtDX9NvL/8As6WwkgWeyuxcAT52 sPLdMcc/x5/CqEfhi4n1OPUdRnt5pnuDJPEkZ8vy/IaIIoJOfvEknrk1ZJNeeKVt9RfToLJ57z7S beNDKqK5EUcpO5unEgAHJOD2yRcl1xLXw9Nq93aXNusCO0kEigSAqSCOuMZHDZwQQc45rDg8IXll bXNuk9nqNrJcmT7LqMO9Xj8qNIwzYJDII8A4OQeRnpq2GiXVh4YOmQXqRXGXZJBFvji3OWCBWJyg B24znHTHYAqXPiy5tLZGm0ScTSzQwwqJkaOXzSVXEg4yCOR2yD3qePxSo1FLC7sJrafzoopdzqyo ZFcocqTnLIV7HJHY1iy+AzeSBpoNLtoTc28stlaxHyJRG5ZmZSMFiDjp9Se2nH4RjtLPV7DT2htr O7Zbi1VI8G2uBzuHqoZUYDscjpjC1A27TUFvLu9hjQ7LSQRGTIwz7QxA+gYD65HaqHhzxJD4jink gt5IliK4LMrZDDIBweHH8S9V49akt9Gli8Mzaabox3dxFJ5t1EMETSZLOv8AwJiQOwAFZnh/w1f6 RrL3fm2dvZSQlDp9oriJX+X96ATjJ28jHHqSSSwJj4xtFj13dbyrLpO4tGSMzIo+8vtnIPp+Iq8d fgHiZdE8p95h3+f/AAeZyRF/vbQW+grH1fwZJqWlX8Md2sF3NczSwzBchUkADIw7ggfmFPapZPCT uHvftT/2t/aH21JDNJ5QIbaFKZx/qQIycZxmlqAaf4wmvrGyuv7GnjjvyyWreehDuFZgrc5XOxuc EVHH4yu20+9vH0N0S1uRZ4+0oS03mrFt6dMtnPtVnwv4P07w/YWgaztH1GFCGu0iAYk5yQTz0OKi k8JvNoeo6bLLC63mqfbSGTK7PPWQoR34Uj05o1A1NO1lrvUZ9OurKS0vIYUnKM6urIxYAhlPqp4I H41XtvE0Nzodpqgt5FS5u1tVQsMgmbysn2zzTtI8PQaFql4+nR28Gn3YV2t0j27JRxlcfwkduxGR 1NUIPDV/CltpouLUaTb332xGCt5zfvDKqEdBhj97PIHQUwJbXxabu3N4mlXJsGEpjuFdW5RWJDqD mPO04z3wDgnFXND1i+1iCC6l0k2trPAs0chuFckMAQMDpwf0rHk8I3tzdrNPJp6TokivfQQeXPd7 o2QCUDAxyGPXJHAWpvCvhmfw/wDZ0NhocQitxA9xaW5SaTAHU45yQCaWoHV1znwv/wCRavv+wve/ +jmro65z4X/8i1ff9he9/wDRzUpDidrRRRUFBRRRQAV5/wDD7/kHa3/2HL7/ANHGvQK8/wDh9/yD tb/7Dl9/6ONVHcTOh1ixbU9Ev7BJPLa6tpIQ/wDdLKRn8M1i+VqeqSaRbzaS9gtlOs00ryRsnyIR ti2sWOSepA+XPfiunrE1+91CC90ez06aCB725eN5JoTKAqxO/ADL1KAdaskxbnw9qM+i67a+Qwe8 1qO5i2ShWMQkhJYEHggIx9ePpVbWvCl6l3cPYJf3UTCybc17vmzHcM7hGkbghSCOQMmtD/hINWk1 M6Cps11MXLxm68ljF5SxJJuCb87v3irjdjqc9qR/EGqw6unh13szqckqhLsQt5XlGN33GPdndmNl xux0PtSAhfR9Q1GfSkMOt2sdvePLLPdXUJlVTBIo2lHbjcVGP9r641NB0u706x1O0uUeWd5mYXry BmuwVAVm5yrAAIRgD5cjg0w6lrNjrWkadfNZyrdzzIZoY2Quiw7wdpY7TuyDycgZ4zgZt54t1C08 SJalIPsKX0kE52ncIwtuA2c9mnyfYUAUbXwxrlosFxbw+VeLaW9kzCVfljaAJKev8Dqje+zjOal0 jwfqFtrjMs11ptkkE8UbWskWSDdzSIpyGONjqe3X14puo+M9TTWLq2heC3tFvoreGY2rzvtKT7yU U5b95AQMduauS+KNRsZNNkZ0v7SQTy3b/YZLaRYk8sZVGJJ27yx9QCBzRoBb02zuPDuq3UFpot5c WDx28cEsUsOFCJtO7fIrfoaxdG0XV7HSZLKbT9a85hcqALu3Nr85fadvmbsfMO3WtDUNd1mTTbm/ 0+9sY4odRS0VWtjL5ivLGgbcHHZ89Oadq2ta5pE7R3N3awxRQB0upNPlMNw53ZDOrEQgYUfNnqTz 0oAow+FtUjitbU24+yWV1a3cC+YvDtNE83fjZtmPuJcDOKj0bRdXsdJksptP1rzmFyoAu7c2vzl9 p2+Zux8w7da7K+1F4rrTLWDYZLyU5bqFjVSzEeucBR/vZ7VyWm+Nb6OxtbzUZIp45tOkvpIxYyWx TbGH2o7sVl7j5R79KALdl4c1DT9Y0JoIl/s+PM9zGXGYJvIZG2+oYsCQOhBP8VRXOgap/wAI/qEC 2szTSa79tRYJUWQw+er7lJYANtBIyRzWje3viPTtCvNVmm02ZY7CW48pIXQwusZZcEsd4yMH7vr7 VRtvGUlqDNe3EV/YrAGknt7RrfyZDIiKrNI+zB3k5yMBDnrQAr6PqGoz6Uhh1u1jt7x5ZZ7q6hMq qYJFG0o7cbiox/tfXGx4Z0660uO+t7tHklNyX+2vJva7UqArNzkMFAUjAHy5HBp8GuGe800+U0dt frKiB9pZZU5xlSQQVDnIJ+6PWtqmAVz/AMOP+Qbrn/Yev/8A0ca6CvNfC3hKw1g69d3Fzqcch1y+ Xbb6hNCnEzfwqwFKSuNHrlFeXaloEPhvXfC9xp9/qwe41eO3lWbUZpVeMxSkgqzEdVFeo1DVigoo opAeffDP/kTE/wCv28/9KJK6+vNvB/ia28PaC2m6jp2spcx3lyzBNMncYaZ2BBC4PBFb3/CwdJ/5 8tc/8FFx/wDEVomrENHV0Vyn/CwdJ/58tc/8FFx/8RR/wsHSf+fLXP8AwUXH/wARTugsdXRXKf8A CwdJ/wCfLXP/AAUXH/xFH/CwdJ/58tc/8FFx/wDEUXQWOrorlP8AhYOk/wDPlrn/AIKLj/4ij/hY Ok/8+Wuf+Ci4/wDiKLoLHV0Vyn/CwdJ/58tc/wDBRcf/ABFH/CwdJ/58tc/8FFx/8RRdBY6uiuU/ 4WDpP/Plrn/gouP/AIij/hYOk/8APlrn/gouP/iKLoLHV0Vyn/CwdJ/58tc/8FFx/wDEUf8ACwdJ /wCfLXP/AAUXH/xFF0Fjq6K5T/hYOk/8+Wuf+Ci4/wDiKP8AhYOk/wDPlrn/AIKLj/4ii6Cx1dFc p/wsHSf+fLXP/BRcf/EUf8LB0n/ny1z/AMFFx/8AEUXQWLHws/5E6T/sJXv/AKPeu1ri/hbHNH4M 3TW88BkvrqVUnjaNtrTOQSpAIyDXaVkWFFFFABRRRQAUUUUAFcF8Pv8AkAXn/YVvv/Sh672vKPDP ia28PWd9p+oafrC3C6ldv+70yd1KtO7AhlUg5BFVHcTPRaK5T/hYOk/8+Wuf+Ci4/wDiKP8AhYOk /wDPlrn/AIKLj/4iruibHV0Vyn/CwdJ/58tc/wDBRcf/ABFH/CwdJ/58tc/8FFx/8RRdBY6uiuU/ 4WDpP/Plrn/gouP/AIij/hYOk/8APlrn/gouP/iKLoLHV0Vyn/CwdJ/58tc/8FFx/wDEUf8ACwdJ /wCfLXP/AAUXH/xFF0Fjq6K5T/hYOk/8+Wuf+Ci4/wDiKP8AhYOk/wDPlrn/AIKLj/4ii6Cx1dFc p/wsHSf+fLXP/BRcf/EUf8LB0n/ny1z/AMFFx/8AEUXQWOrorlP+Fg6T/wA+Wuf+Ci4/+Io/4WDp P/Plrn/gouP/AIii6Cx1dFcp/wALB0n/AJ8tc/8ABRcf/EUf8LB0n/ny1z/wUXH/AMRRdBY6uuc+ F/8AyLV9/wBhe9/9HNVf/hYOk/8APlrn/gouP/iKsfC9JV8KXEktvPB52pXcyJPE0bbGlYqSrAEZ BqJMaO1oooqSgooooAK8/wDh9/yDtb/7Dl9/6ONegV5F4f8AE8fhh9a0/UNH1wzHV7yZWh06SRGR pSVIYDBBFVHcTPS6zdX0aPVmtHN3c2s1pKZYpbcqGBKMh+8pGMMe1c1N8UtGtmiWfTdeiMr7Iw+m SLvbGcDI5OAePan/APCzNL/6BHiH/wAFUv8AhV3RNja/4Rm0EC7bi6F4s32j7dvBmMm0KSSRtIKg Lt27cAccCk/4Ri08ssbi6N6Zxc/bi6+cJAu0EcbcbSV27duCeOTWN/wszS/+gR4h/wDBVL/hR/ws zS/+gR4h/wDBVL/hS0A2D4XtjFu+2XgvftH2r7dvXzvM2bP7uzGz5du3bjtnmmDwhpxidZZLmZ5Y 7iOaWRwWl84KHZsDGcIoGMAAdKyv+FmaX/0CPEP/AIKpf8KP+FmaX/0CPEP/AIKpf8KNA1NGXwZY t9naG7vbeW3EIjliddwMSyKD8ykEkSvnjmr9roiwXVvdT315eTwLKiPcFM7X2ZHyqB/AMfU1z/8A wszS/wDoEeIf/BVL/hR/wszS/wDoEeIf/BVL/hRoBsW/hPTLTSJNLgEqWj3S3QQP9xlkWQKvHCgq Bj04p9/4dhvrm4mW+vbUXSBLmO3dQswAxzuUkHHGVKnHesT/AIWZpf8A0CPEP/gql/wo/wCFmaX/ ANAjxD/4Kpf8KNAOiutLDXGlzW2xDYyYVDnBjKFGX8AQR7qB3qhY+ELO0jtoZry9vra1iMVvb3To Y41KGPoqjPyEr82eCazP+FmaX/0CPEP/AIKpf8KP+FmaX/0CPEP/AIKpf8KNANJ/B9pPbNbXV/qF zbiCS3hjllUiBXQoSpCgs20kAuWIyfWti5sRc2ItVnngC7dskLAMNpHqCCOOQQQR2rlf+FmaX/0C PEP/AIKpf8KP+FmaX/0CPEP/AIKpf8KNANez8OR2N3Y+U2baz8+Zd2NzzSnlsABQAC4wP7/QY53a 4v8A4WZpf/QI8Q/+CqX/AAo/4WZpf/QI8Q/+CqX/AAp3QHaVyfgH/jy13/sPX/8A6Oaq/wDwszS/ +gR4h/8ABVL/AIVN8PDLJoupXUltcW63erXdxElxEY3KPKSpKnkcGgCXxh/yEvB//Yei/wDRM1d3 XnPxD1CLSv8AhF76aOaSODXImZIIzI5HkzdFHJNXf+Fq6P8A9AnxF/4Kpf8AColuUtjuaK5Sx+Iv h2+tFuEnuIssymOa3dXVlYqQRjggg0VIzq6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigDiPiF/yEfB3/AGHE/wDRMtdLXNfEL/kI+Dv+w4n/AKJlrpauOxMgoooq iQooooAKKKKACiiigAooooAKKKKACiiigAooooA5Pxt/x++Ev+w9F/6JmrrK5Pxt/wAfvhL/ALD0 X/omausoGeHn/j/1X/sKXv8A6UyUUH/j/wBV/wCwpe/+lMlFZFn0FRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc54v8M3PiSHTTZamun3Wn3i3cUrW/nAkIy4K7 l/vevas3/hGvGv8A0Otl/wCCQf8Ax6u1op3A8q8PN41163vZf+EqsoPst9PZ4/sgNu8tyu7/AFgx nGcdvU1r/wBi+Nf+hysv/BKP/jtN+H3/ACDtb/7Dl9/6ONddVrYhnJ/2L41/6HKy/wDBKP8A47R/ YvjX/ocrL/wSj/47XWUU7Acn/YvjX/ocrL/wSj/47R/YvjX/AKHKy/8ABKP/AI7XWUUWA5P+xfGv /Q5WX/glH/x2j+xfGv8A0OVl/wCCUf8Ax2usoosByf8AYvjX/ocrL/wSj/47R/YvjX/ocrL/AMEo /wDjtdZRRYDk/wCxfGv/AEOVl/4JR/8AHaP7F8a/9DlZf+CUf/Ha6yiiwHJ/2L41/wChysv/AASj /wCO0f2L41/6HKy/8Eo/+O11lFFgOT/sXxr/ANDlZf8AglH/AMdo/sXxr/0OVl/4JR/8drrKKLAc a3hTxDe6lpdxq/ie3u7ewu1u1hi0wQlnCso+bzDgYc9q7KiigDw8/wDH/qv/AGFL3/0pkooP/H/q v/YUvf8A0pkorIs+gqKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA8w8E65pFha63BeapY20w1y+JjmuERsecexNdP8A8JT4e/6D2l/+Bkf+NeAeLP8Akcdb /wCv+f8A9DNY9VzCsfS//CU+Hv8AoPaX/wCBkf8AjR/wlPh7/oPaX/4GR/4180UUcwuU+l/+Ep8P f9B7S/8AwMj/AMaP+Ep8Pf8AQe0v/wADI/8AGvmiijmDlPpf/hKfD3/Qe0v/AMDI/wDGj/hKfD3/ AEHtL/8AAyP/ABr5ooo5g5T6X/4Snw9/0HtL/wDAyP8Axo/4Snw9/wBB7S//AAMj/wAa+aKKOYOU +l/+Ep8Pf9B7S/8AwMj/AMaP+Ep8Pf8AQe0v/wADI/8AGvmiijmDlPpf/hKfD3/Qe0v/AMDI/wDG j/hKfD3/AEHtL/8AAyP/ABr5ooo5g5T6X/4Snw9/0HtL/wDAyP8Axo/4Snw9/wBB7S//AAMj/wAa +aKKOYOU+l/+Ep8Pf9B7S/8AwMj/AMaP+Ep8Pf8AQe0v/wADI/8AGvmiijmDlO6iljnudRmhkWSK TUrxkdDlWBuJCCCOoorT8J/8izZ/8D/9DaipKP/Z ------_=_NextPart_001_01C75213.70BD4C5E Content-Type: image/jpeg; name="SPEERMINT Document Flow - v1-B.jpg" Content-Transfer-Encoding: base64 Content-Description: SPEERMINT Document Flow - v1-B.jpg Content-Disposition: attachment; filename="SPEERMINT Document Flow - v1-B.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAJcAh8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAo6jqttpb2SXJcG9uVtYtq5+cqzDPoMKawm8f6 eby8trfS9cuzaXD20slrp0kqCReoDDj0pfGn/H14V/7DkX/oqWub8MW2ry3vidrDxHbadD/bt0DD LZrKScr82Sw9uPagDp9R8b2el2iXVzpOuCFrc3DuunSERKCc7+PlI2kkHtg96Z/wn2mrpM2pS6fr EFvG0Sr51g6mYyMFQRg/e5I6eoqx4mEo+HOtLNcJcyjSrgPMibRI3lNkgAnH0zWF4vWR/hpo6QyC KVrnTAjld20+dFg4749KAOi0rxTFqt8LVNI1q2JUt5l3p8kUfHbcRjNTa54js9CMEc0V3c3VwGMF rZwNNLIFALEAdAMjkkDmk0mw1y0uXfU9civ4imFjSyEO1sjnIY54zx71jeKFsrnxPptuuq3Gja0t tK1nehUMcikqHiIfhzwrbcds5oAvjxrpH9iahqjm5iXTgPtdvLAyTw55GUPPIOR2NMtfHGmzXcFt c2eq6c1xIsMLX9hJCkkh6IGIxk+hxXEa9qN7J4Z8b6VfS6fe3dpZwO2pWcHl+aGLbUlAJ+ddvQHo w6V1974c17XLixTWtV082Frcx3TQWdk8bSvGwZAWaRsLkZOBk0AObx/p5vLy2t9L1y7NpcPbSyWu nSSoJF6gMOPSrF/4zstPi00y6fqrzagkjw20dk7TAJjduTqPvCuU8MW2ry3vidrDxHbadD/bt0DD LZrKScr82Sw9uPar3iSLUH8VeEI4NZgguxbXge9NuGRyFiydm7Az9eKANweNbFNJ1DUrrT9Xs7ex jEkhurF4iwJx8oP3j9PWox4702OeGO+sdX0+OaRYknvbCSOLexwql8YXJOOcCsXxhDqUPw38Ri/1 yDU2a3Hl+XbLF5fPOcMc549OlU/E9prdtPptr4p1uO98M3dzHHdPBZrAY5AwaMSEs37tmCgkYx7Z oA7a18TaZeeJ7/w7FI/9o2UaSyoyYBVgDlT3xuXP1pE8UaW/ia68PpK7X9rbfapgEO1U44z6/Mpx 6EVwl66aV8Q9Z8SMQkdhqNrBdOTgC3mt40Yn2D+U3/Aad4dhc+Ll1KdWW41XRLq/kDHJUSTR7F/4 DGEX8KAOxTxroj/2Bm4ZBryF7Euu0PgKcH0J3DA7mreoeIbTTr9rF4rqa5W0a7EVvCZGZFdUOAOS csOK80sNGtdf0X4c6beKfKm0S4wy/ejYRwlXU9ipAI+la3hfVL28+Ji6fqwxq+maPLb3Thdqzfvo isq+zrg+xyO1AG5F8RLCe8ltI9G8QtcRBTLGNLkzGGztLDtnB6+lbuu63aeHtLbUL0TNEJEjCwxl 3ZnYKoCjqSSKx9F/5KN4r/697D/0GWmfEYhfDVsSQANVsCSf+vmOgC5p/jLTL6/hsZYb/T7qckQR ahZyQGYgZIQsMEgds5o1Pxjp+nahJYRWuo6jdw7TPFp1q05gDdN5HAyOcZzjtWV44u7a+l0HTbO4 il1NtXtpoo42DPGqNudyP7oTcCfeneBbiG0l8Q6bdSCPUo9WubidZMKzo7bkkA/u7Noz/s/hQBu2 3ijRbvQZNbjv4xp8W7zZZAUMRU4KspGVYHjaRnpxzVGy8b6bd38FpLa6nY/aX2Wst9ZvBHO2MgKz DqR0BwTiuD1JlupNf162YP4cTxDYTzFFBjlSIIs8gH8ShtpJ5z5ZNeiaxreiRRaaLkQ35vLqJbKK MJKXcnh1BOMLyxbsBmgC7pesWmsfbfshc/Y7p7SXcuP3iYzj1HI5rJu/Hug2NjaXlxPKsF1qD6cj eUeJVZlbPooKHn0qh4Kubewu/FdrdXEMM6a3cTtHJIFIjdUZWwexHeuNTToNe8O+GraXm01PXtSa N8ZzHIt0VcfgQR+FAHp3iXxPpnhTTo77VHkWGSZYUEabmLHOOPwNU77xtY2Wr3emrp2sXk9oUExs 7F5lUsoYDK+xFeb+KL+bxP4Nubm7B87Q7OKC5DdRevOqSfiFjP4S11MEGqzePfFh0/XrfTEE1tuW W1WUufs6c5LDFAHR3HjPSbGx0271EXWnpqF19khW8gaJlkOcbgfug7ep9RV3U9etNKvrOynSd7i8 SZ4UhjLlvKTewwO+Og7muR8WaYupHwfpms3EWqJPqMsc8giEayA20/8ACCcYGB17ZrJtLu9t/iV4 V8Oaq7y3umfbPKuSuBc2zRYjfP8AeG0q3uue9AHTf8LI077f9g/sbxD9r8rzvI/suTfszjdjHTPG a6HU9atdI0GbWLxZktYYhK48s7wOONvXPPSuf/5rN/3L3/txU3xLz/wrjXcEA/Z+M/7woAtad4th 1G/itF0bXbcyEgS3OmyRxrwTyxGB0rR0TWLTX9Ig1OxLm2n3bC67T8rFTx9QaqaZp3iC2vRJqPiC G9t9pBhWwERJ7HcGP8qxfhbPCvw70mMyxh8yjaWGf9c/agDU1Pxjp+nahJYRWuo6jdw7TPFp1q05 gDdN5HAyOcZzjtUsHi/RbqysLuC6MkF7d/YoyEIKTYb5HU4KH5SMEdcetY/gW4htJfEOm3Ugj1KP Vrm4nWTCs6O25JAP7uzaM/7P4VztzCdTsfHOt6WVeyhvbe9sZEGFkntkRpXTHUEptzznB60AegN4 k01fFK+HDK39otb/AGkLt+XbnGM/3upx6CrFhq1rqVxfw2rMxsbj7NMxXA8zarEA98Bhn3rzszxy 2J8foyeX/bizLMMnNkP9FP4YJf8AWuv8DQOnhS2u50VbnUWe/mwMZaZjIM/RWUfhQA/UvGFhp99J YxWuo6jcw7fPj0+0ebycjI3kcAkc4zn2qaDxXo93Dpc1tdedHqc7W9uyKf8AWKrMysOqkBGBB78V i+B7m3spPEWn3c6R6hHq9zcTrKwVmR23JJj+6U2gH2rG1q6tdeuPDMvh9jpyS69OEu0t0IlcQTbp VHIcMQRuPJ5oA7271i0stX07TJi/2nUPN8gBcj92u5sntwagfxLpkfiiPw60rDUJIPPVdvy45+Xd 2bCk49ATXH31lqOm/EbwlJqmuvqEZW9IMtvHCIgIRk5UD9fSuelPiG80q68XQ+H1kc6gNYtrprtU cW8QKrH5e3JBh3cZGS9AHpOreLbPSdXGltZald3RgFwVs7VptqFioJx05U1HF4106ezupoLTU5Z7 R0S4skspPtERYEqTHjOCBnPSudnN/rnxDS78P6vFZJNoEEwlktRMJEaWQgYLDHWrXw/WRtU1+XWJ 2k8TLLHBfKYwiCNFPlGIAfcYEnJ5znPSgDR03x7YatffZLbStc3LOLeR306RUifgkO3RcAgnPTNd VXK+C/8Aj68Vf9hyX/0VFXVUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUART2tvcmIzwRSmGQSxGRA2xwCAy56HBPI9TWbP4U8OXVxJcXGgaVNNIxZ5JLONmY nqSSMk1r0UAVY9NsYdOOnxWVuliUZDbLEoj2nORtxjBycj3p8llazW6W8ttC8MZUpG0YKqVIKkDo MEDHpip6KACqmo6Vp+sW32bUrG2vIM58u4iV1z64I61booAz4NC0i10ttMg0uyjsH+9bLAojbp1X GD0HX0rQoooAyJ/Cnhy6uJLi40DSpppGLPJJZxszE9SSRkmnzeGtCuLa3tp9E02W3t9wgie1Rli3 HJ2gjAyRzitSigDKh8MaBbRTRQaHpkUc67JkjtI1Ei5zhgByM9jV+6tLa+tntru3iuLeQYeKZA6s PcHg1NRQBUfStOkS5SSwtWS6AFwrQqRMAABv4+bAAAz2FSfYrTzxP9lh85YjCJPLG4RkglM9duQO OnFT0UAVY9NsYTbGKyt0NqhjtysSjyVOAQnHyg4HA9BUn2O1+3fbfs0P2vy/J8/YPM2Zzt3dduec dM1NRQBElrbxXMtzHBEk8wUSyqgDOFztDHqcZOM9MmmXljaajbNbX1rBdW7EFop4w6nHIyDxViig DP0/QtI0mR5NN0qxs3cbWa2t0jLD0JUDNJqXh/RtZkik1PSrK8ki/wBW1xArlfYEjp7Vo0UARR28 EVsttHDGkCrsESqAoXpjHTHtVCw8N6HpV293p+j2FrcOMNLBbqjY9MgdK1KKAMvUvDeh6zNHNqej 2F5LHjY9xbq7DHTkjp7VdaytW+z7raE/ZjmDMY/dHGMr/d4JHHY1PRQBTOlac0FxA2n2phuZPNnj MK7ZX4+ZhjDHgcnngVXvPDOgahdPdXuiabc3D43yzWkbu2BgZJGTwAPwrUooAo22jaXZxQx2um2c EcEhliWKBVEbkYLKAODgkZHrU8lnay3cN3JbQvcwBhFM0YLxhuDtbqM98VPRQBF9lt/tf2vyIvtP l+V52wb9mc7d3XGecUXNrb3ts9tdQRTwSDDxSoGVh6EHg1LRQAVjx+E/DcU6zx+H9KSZGDrItlGG DA5BBx1z3rYooAztS8P6NrMkUmp6VZXkkX+ra4gVyvsCR09quJbQRWwto4Y0twuwRKoChemMdMe1 S0UAVhptiNO/s8WVuLHZ5f2YRL5e3+7txjHtU6IkcaoihUUAKqjAAHYU6igDN1Lw9ouszRTanpNl eSxfce4gVyo9ASOnJ4q2bG0ItwbWDFscwDyx+6ONvy/3eCRx2qeigCvc6fZXrK13aW85RXRTLGGw rDDAZHQjg+oqSKCKG3S3iiSOFFCJGqgKqgYAA6AY7VJRQBUtdL0+xZWtLG2t2SIQqYoVQiMEkKMD 7uSTjpkmpBZ2ovTei2hF2Y/KM+wbymc7d3XGecVPRQBFBa29sZTBBFEZpDLKY0C73IALNjqcAcn0 FS0UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAc54y8RXnhzT7F9P0+O+u729js4opJvKUMwY5LYP939axf+Ei+IP/Qo6X/4Nf8A7CrX xC6+Ff8AsP2//oEldDVRVxNnKf8ACRfEH/oUdL/8Gv8A9hR/wkXxB/6FHS//AAa//YV1dFVyoVzl P+Ei+IP/AEKOl/8Ag1/+wo/4SL4g/wDQo6X/AODX/wCwrq6KOVBc5T/hIviD/wBCjpf/AINf/sKP +Ei+IP8A0KOl/wDg1/8AsK6uijlQXOU/4SL4g/8AQo6X/wCDX/7Cj/hIviD/ANCjpf8A4Nf/ALCu roo5UFzlP+Ei+IP/AEKOl/8Ag1/+wo/4SL4g/wDQo6X/AODX/wCwrq6KOVBc5T/hIviD/wBCjpf/ AINf/sKP+Ei+IP8A0KOl/wDg1/8AsK6uijlQXOU/4SL4g/8AQo6X/wCDX/7Cj/hIviD/ANCjpf8A 4Nf/ALCuroo5UFzlP+Ei+IP/AEKOl/8Ag1/+wo/4SL4g/wDQo6X/AODX/wCwrq6KOVBc5T/hIviD /wBCjpf/AINf/sKP+Ei+IP8A0KOl/wDg1/8AsK6uijlQXOU/4SL4g/8AQo6X/wCDX/7Cj/hIviD/ ANCjpf8A4Nf/ALCuroo5UFzlP+Ei+IP/AEKOl/8Ag1/+wo/4SL4g/wDQo6X/AODX/wCwrq6KOVBc 5FfGXiuy1XSoNa8NWNta394loJYdQ8xlZgSDt2c/dNegVwnjP/j88Kf9h+3/APQJK7uoasxoKKKK QwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKAOM+IXXwr/wBh+3/9Akroa574hdfCv/Yft/8A0CSuhq4k yCiiiqJCiiigAooqG7F01q4s3hS4x8jTIXQc9wCCePegCaiuAl8Wa7a6Laajd3Ojwpc6i9jva3kC xBXkUux8znPl9OOtPu/GdzbNpiDWtBaK7ecPe+W/lJ5aoQuPM+98x7+nFFx2O8orirfxneSX+jxv awGzu5p45LlN211V444pI8/ws8qjnPt7yweL7q41u5tUt4RbJfm1jc53MqwTOzHnH34SB/s0XA7C iuMsPHDTaLpl7e26W87sft0QydifZpJw6eoYIMZ9SOoNW/7c1iztbTUdRt7MWd4yIIoS3mW7P9zc Tw/zFQcBcZzzii4HUUVgN4gmXwppmpC3je81BLdYoslU8yXb1PJCjJJ68Cq134g1PRZfsmo29rc3 M6K1m1uxiSRjLHFsYMWK4aWM55yCeOOS4HUUVyra1rME91aeZo9/ewRef5FrIVlwCu6MxlidxU5V umeCBkZ0tG1ltcllu7RV/skIqwyspDzSdWIz0UcL0zuDenIBsUUUUCCiiigAooooA5bxn/x+eFP+ w/b/APoEld3XCeM/+Pzwp/2H7f8A9Akru6iW5aCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBx nxC6+Ff+w/b/APoEldDXPfELr4V/7D9v/wCgSV0NXEmQUUUVRIUUUUAFFFFAHP3HhSGTS7Wzhvrm 3a1vnvopkCMwdmdsYZSCP3h7dhU0GgONRsr+81S6vLi080RmRI0GJAoIIRR02/rW1RQM5w+DrEwy QLPOsPlXEUMY24txK0b/ACccbWjBX0zjoBiSDwlY281vJHNcfuShALA52wPCM8f3ZCT7it+iiwHP /wDCH6a0mjyP5jNplubZckYmj8to8OMc4DMR6ZPqaWPwuuy1gudSu7mytCGt7eQJ8pAIXcwXLbQe MnqATk81v0UAc5b+FGj0tNNuNZvbi1hSNbcFIkaBoypR1ZUBJG0dcg9walfwxHd+dJqV9c3dw8Yi jm+WMwAOHBTaBhtyo2TnlB2GK3qKLAY1loDQaqmpXmoz3tzHE0MbSRxoFVipYkIoyTtXrxxwBV7T NPi0vT4rKFnaOPOC5GeST2+tW6KACiiigQUUUUAFFFFAHLeM/wDj88Kf9h+3/wDQJK7uuE8Z/wDH 54U/7D9v/wCgSV3dRLctBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4z4hdfCv/Yft/8A0CSu hrJ8caHqut6fpp0V7Jb2w1CO8QXrMI22qwwSoJ/i/SsjyPij/wA8vB//AH+uf/iKqLsJo62iuS8j 4o/88vB//f65/wDiKPI+KP8Azy8H/wDf65/+IquZE2Z1tFcl5HxR/wCeXg//AL/XP/xFHkfFH/nl 4P8A+/1z/wDEUcyCzOtorkvI+KP/ADy8H/8Af65/+Io8j4o/88vB/wD3+uf/AIijmQWZ1tFcl5Hx R/55eD/+/wBc/wDxFHkfFH/nl4P/AO/1z/8AEUcyCzOtorkvI+KP/PLwf/3+uf8A4ijyPij/AM8v B/8A3+uf/iKOZBZnW0Vwepax460MwDVIvDubhikP2Rpn+YY+9uAwOR0zV/yPij/zy8H/APf65/8A iKpq0VJ9RJ3bXY62iuS8j4o/88vB/wD3+uf/AIijyPij/wA8vB//AH+uf/iKnmQ7M62iuS8j4o/8 8vB//f65/wDiKPI+KP8Azy8H/wDf65/+Io5kFmdbRXJeR8Uf+eXg/wD7/XP/AMRR5HxR/wCeXg// AL/XP/xFHMgszraK5LyPij/zy8H/APf65/8AiKPI+KP/ADy8H/8Af65/+Io5kFmdbRXJeR8Uf+eX g/8A7/XP/wARR5HxR/55eD/+/wBc/wDxFHMgsyTxn/x+eFP+w/b/APoEld3XnL+H/Hmr6toz6z/w jcVlYX8d45s5ZzI20MMAMuP4q9GqG7spBRRRSGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQBwfxH/1uif8AXw3/ALLXeVwfxH/1uif9fDf+y13ldFT+DD5/mYw/ iS+QUUUVzmwUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcFZa94t1me8bTYdP8mCdosS AgjHTvzxXTa74is/DyQvexzlJSQrRICAR2PIrh/B3iqw02S8gljuXlu7vdEsaA5zwB16110KcuSU +W/Y56s1zKN7G95vj3/nhpf5n/GjzfHv/PDS/wAz/jXY0Vn7b+6vuL9n/eZx3m+Pf+eGl/mf8aPN 8e/88NL/ADP+NdjRR7b+6vuD2f8AeZx3m+Pf+eGl/mf8aPN8e/8APDS/zP8AjXY0Ue2/ur7g9n/e Zx3m+Pf+eGl/mf8AGjzfHv8Azw0v8z/jXY0Ue2/ur7g9n/eZx3m+Pf8Anhpf5n/GjzfHv/PDS/zP +NdjRR7b+6vuD2f95nHeb49/54aX+Z/xo83x7/zw0v8AM/412NFHtv7q+4PZ/wB5nHeb49/54aX+ Z/xo83x7/wA8NL/M/wCNdjRR7b+6vuD2f95nHeb49/54aX+Z/wAaPN8e/wDPDS/zP+NdjRR7b+6v uD2f95nHeb49/wCeGl/mf8aPN8e/88NL/M/412NFHtv7q+4PZ/3mec61ovjLW2tTdwWObd9yeW+O Tjrk+1avm+Pf+eGl/mf8a7Gim8Q2knFaeQlRSd7s47zfHv8Azw0v8z/jR5vj3/nhpf5n/Guxope2 /ur7h+z/ALzOO83x7/zw0v8AM/40eb49/wCeGl/mf8a7Gij2391fcHs/7zOO83x7/wA8NL/M/wCN Hm+Pf+eGl/mf8a7Gij2391fcHs/7zOO83x7/AM8NL/M/40eb49/54aX+Z/xrsaKPbf3V9wez/vM4 7zfHv/PDS/zP+NHm+Pf+eGl/mf8AGuxoo9t/dX3B7P8AvM47zfHv/PDS/wAz/jR5vj3/AJ4aX+Z/ xrsaKPbf3V9wez/vM47zfHv/ADw0v8z/AI0eb49/54aX+Z/xrsaKPbf3V9wez/vM47zfHv8Azw0v 8z/jR5vj3/nhpf5n/Guxoo9t/dX3B7P+8zjvN8e/88NL/M/40eb49/54aX+Z/wAa7Gij2391fcHs /wC8zjvN8e/88NL/ADP+NVLrXvFmj3diNThsPJuJ1ixGCSckZ78V3leOeKtf1h9VWy1BYBJYT70K IRu7g9ehGDW+H/fStyoyrfu1e7PY6K53wfqeqazpTX2oiJVkfEIjQrkDqTye/H4V0Vcc4OEnF9Do jLmV0FFFFSUFFFFABRRRQAUUUUAFFFFABRRRQAUUV5do+izeI73X7u88QeIImi1i6t447bVJYo0R HwoCqcDAppXA9Rorg/8AhBYf+hk8U/8Ag6n/AMaP+EFh/wChk8U/+Dqf/GnysVzvKK4P/hBYf+hk 8U/+Dqf/ABo/4QWH/oZPFP8A4Op/8aOVhc7yiuD/AOEFh/6GTxT/AODqf/Gj/hBYf+hk8U/+Dqf/ ABo5WFzvKK4P/hBYf+hk8U/+Dqf/ABo/4QWH/oZPFP8A4Op/8aOVhc7yiuD/AOEFh/6GTxT/AODq f/Gj/hBYf+hk8U/+Dqf/ABo5WFzp/EekJrmh3FkQPMI3RMf4XHT/AA+hNcD8OtBebV5tQuYyEsyU VWH/AC17/kP1IrX/AOEFh/6GTxT/AODqf/GmR+ALWHd5XiDxOm5i7bdYmGWPUnnrW8K04U5U11Mp U4ympdjv6K4P/hBYf+hk8U/+Dqf/ABo/4QWH/oZPFP8A4Op/8aw5Wa3O8org/wDhBYf+hk8U/wDg 6n/xo/4QWH/oZPFP/g6n/wAaOVhc7yiuD/4QWH/oZPFP/g6n/wAaP+EFh/6GTxT/AODqf/GjlYXO 8org/wDhBYf+hk8U/wDg6n/xo/4QWH/oZPFP/g6n/wAaOVhc7yiuD/4QWH/oZPFP/g6n/wAaP+EF h/6GTxT/AODqf/GjlYXO8org/wDhBYf+hk8U/wDg6n/xq18OJLg6RqtvcXt3efZNXureKS7maWTY rYUFm5NJqwJnZUUUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWdrOu6X4dsRe6vfQ2dsXEYklO AWOSB9eD+VaNcZ8QuvhX/sP2/wD6BJQA/wD4Wp4G/wChmsf++j/hR/wtTwN/0M1j/wB9H/Ct6ir5 SeYwf+FqeBv+hmsf++j/AIUf8LU8Df8AQzWP/fR/wreoo5Q5jB/4Wp4G/wChmsf++j/hR/wtTwN/ 0M1j/wB9H/Ct6ijlDmMH/hangb/oZrH/AL6P+FH/AAtTwN/0M1j/AN9H/Ct6ijlDmMH/AIWp4G/6 Gax/76P+FH/C1PA3/QzWP/fR/wAK3qKOUOYwf+FqeBv+hmsf++j/AIVxfjTxP4K1y9sbq08SWAkL CGc7jwnXd07c/mK9Soq6cpU5c0WTNKasznLX4l+ALO1itoPElisUSBEG48AD6VL/AMLU8Df9DNY/ 99H/AAreoqHG5VzB/wCFqeBv+hmsf++j/hR/wtTwN/0M1j/30f8ACt6ijlDmMH/hangb/oZrH/vo /wCFH/C1PA3/AEM1j/30f8K3qKOUOYwf+FqeBv8AoZrH/vo/4Uf8LU8Df9DNY/8AfR/wreoo5Q5j B/4Wp4G/6Gax/wC+j/hR/wALU8Df9DNY/wDfR/wreoo5Q5jB/wCFqeBv+hmsf++j/hUtt8S/Bd5c LBb+IrJ5WztUMecDPpWzXBfFf/kA6X/2ER/6JmpOIXPT6KKKkoK4PwR08R/9h+9/9DrvK4PwR08R /wDYfvf/AEOqjuJnVUUUVZAUUUUAFFFFABRXP6lrUuiandtdMZbV7I3FrGNoJkjOHjHGSW3x4znn dVPTF17UzeQza1JbT6eyWxMVvERLL5SSM7hlPy5kwAu3heuTwXGdZRXmtx4v1S6tLO4S5ntkubiy VltLdZXRZIXdwgKtnLAYyCcV0ui608PmRaveSIJ7ry9Pa+iWCaddqZygC8hmIHA4xxRcDpaK88n1 3XNP0q6nvL66hvWsbiREltont2kWJpFNvIg7bc4kJJUHjio9R17XLPR7m7tLzVXhW3j3TXthHE6S tNGoEY8tQ2UaTqpA2rzzRcLHo9Fcb/aOoxx29tHeauJb68jtlm1K1hQwrtkdmQIigkhMfNkAkcdQ bk1xqOl6hp9m+rfbFnvkRvMjjEwjMUpw21QMbkBBAB4I5ouB01FedWWuau/hG41Zr/Vzcpp7XAM9 rAtuXx/CRGGPXgE9ua3IrrU9UbVb2HVTp8VjdSQRQPFGYmEYGWlJG7BOTlWXC4ouB1NFFFAgoooo AKKKKACuf+HX/Hn4h/7D97/6HXQVz/w6/wCPPxD/ANh+9/8AQ6mRUTsqKKKgoKKKKACiiigAoooo AKKKKACiiigAooooAK4z4hdfCv8A2H7f/wBAkrs64z4hdfCv/Yft/wD0CShAdDRRRWpmFFFFABRR RQAUySWOJQ0jqilgoLHAySAB9SSAPc0+sjxJHJLpcKxozsL+yYhRk4FzESfoACfwoGXxf2bW81wL uAwQlhLKJBtQr97cegx3z0p89zBbW7XE88cUCDc0kjhVA9STxXltzpOpL4e1rSks7kwao13ePiM5 Vo5Jcrj/AG9tuAO4Zq6vWIrufSoF1G0eCKC4je3nsibl0IDYeWIxjjoCBuxuzkbc0rgbsmt6TDBB PJqlkkNxnyZGuECyY/unPP4Ulzruj2ZjF1qtjB5i70824Rdy+oyeR71wdrZ6le+I9OltILWNBNds b06dKIZsxQjeYi42kkFchsEqSOtNl0y48OeKQouljjexZmnXSJLiIu9xI5RUQ/IBu6Enii4Hoc2q 6dbRQSz39rFHcY8l3mVRJnkbSTz17UtzqdhZLI11fW0CxkBzLKqhSegOTxntXKwzWtrq9/eavbyX MN3aQC1cafIwaMId8YTBKktlth5+YdccUJ9NvppQLSylsw1xp5jWeEzCFViIIbn5tvQnPXvRcDub TU9PvwDZ31tcht2DDKr524z0PbcufqPWltdQsr5pVtLy3uDEdsghlV9h9Dg8VyPiHStWkh+zwus1 2dIv0823g8pWZntyFAycMQCBz2z2rX0250q51e3/ALP0uaN4rZ0ab7M0AgXKYjYMBycdOcbT0zyw OgooooEFFFFABRRRQAVwXxX/AOQDpf8A2ER/6Jmrva4L4r/8gHS/+wiP/RM1J7DR6fRRRWZYVwfg jp4j/wCw/e/+h13lcH4I6eI/+w/e/wDodVHcTOqoooqyAooooAKKKKAKl9pdlqTWrXcAla1mWeE5 I2uvQ8Hn6HiqN9o+jahqbRzs63k0OZYobqSIzRj5cuqMNwG7GSD1xWzXN6mH07xfa6xJBczWrWEl qxtoGmZH3oy5VQTggNzjAxzjNAwuz4RtJLe6urmwtyZleEtcbF3wgxjAyBhclT2Hertz4p0GzuTb XOr2UUwCko0wzgjI/MEGuVgsrqxtobiSDVbC6limKzWtsLoMHnkkEUsW1sEBlORj7zDcMVU0yPVN N1a9e5XVdM82K0/c6bpvnwkrAisAdjYAIIwD279aVwOovNA8NaZYSNfEQWPltCFuL2QRRq6lSEVm whIJUbcHBwKt3sugar4bY3N3bS6Q+xTKtxtTIcBRvUgghgB1zmoddjmTVdG1MRTT2lpJJ50UUZdl LptWTYOTjkcAn5zx1rIv7S48S3Qs4tIFpp7yy3Ez3cLKLr5BGpZRggksxAPOI1JxkCgDSv7Xw1pM H2fVNQaJLhlZBfapKxBQ5DIXclSDj5lx25qEz+DtKu1im1G2F5HKlwWuLxpJS2wqrFmYkjaxwDxg 8Csz/iYLHBNepqtrqUVq1m97aWv2lLko7DDxlGO1sBw3Gd5G4Yqhpkeqabq169yuq6Z5sVp+503T fPhJWBFYA7GwAQRgHt360AdfJJ4bigHheS6tFBjEAsjcYfaRwvXdkgj3qe78N6Xe3Ms88EhMxBmj W4kWOYjABdAwVuAByDkDBrm72K7j1O5jsrW/WSa+SY2ctqJrS4+ZT5vmbf3ZwoOCwwV4U9+6pgFF FFAgooooAKKKKACuf+HX/Hn4h/7D97/6HXQVz/w6/wCPPxD/ANh+9/8AQ6mRUTsqKKKgozLjxHod ncPb3OtadBMhw8ct0isp9wTkVF/wlnhv/oYNK/8AA2P/ABql4XtbeWPVnkt4nb+1brlkBP363fsF n/z6Qf8AfsUAZ/8Awlnhv/oYNK/8DY/8aP8AhLPDf/QwaV/4Gx/41ofYLP8A59IP+/Yo+wWf/PpB /wB+xQBn/wDCWeG/+hg0r/wNj/xo/wCEs8N/9DBpX/gbH/jWh9gs/wDn0g/79ij7BZ/8+kH/AH7F AGf/AMJZ4b/6GDSv/A2P/Gj/AISzw3/0MGlf+Bsf+NaH2Cz/AOfSD/v2KPsFn/z6Qf8AfsUAZ/8A wlnhv/oYNK/8DY/8aP8AhLPDf/QwaV/4Gx/41ofYLP8A59IP+/Yo+wWf/PpB/wB+xQBn/wDCWeG/ +hg0r/wNj/xo/wCEs8N/9DBpX/gbH/jWh9gs/wDn0g/79ij7BZ/8+kH/AH7FADrS8tr+3W4s7mG4 gbO2SFw6nHBwRxXJfELr4V/7D9v/AOgSVpeEUVLbVVRQqjVboAAYA+es34hdfCv/AGH7f/0CShAd DRRRWpmFFFFABRRRQAVBe3H2OxuLnbv8mJpNucZwM4/Sp6jnhS4t5IJBmORSjD1BGDQBiv4nji0z SL57WQpqEJl2IdzIBA02AMfMcLjt1rOk8a3EOiSam+ko8JRHgeC8WSN9zom13C/I3zg4wQQDg8VN aeGdSSLT7e41SEQ6ZA0Vo9vAVkLGMxq7FmIyFJ4AwTzx0qhqXgW61aO6M9xpkM8sIiaS3siguD5k b7pRv+b/AFeAO2489qWozp9KvL67EpvbS1t9uNnkXfn7uuc/KuO3rVK08QXN88dxbaVJJpUkvlJd LKC5+bbv8vH3M985xzjFSaDpE2leeJIdIiWTbgadZGDJGfvfMc9ePxqrbaFq2n2sWnWGpW0NhDL5 kX+jky7NxYRk7sYzgE4yV44PNMCaDxRBNe6tAbaYR2CNIki/MbhUysmwequpUj1x61nSeNbiHRJN TfSUeEojwPBeLJG+50Ta7hfkb5wcYIIBweKmg8GCyj097HUrqG7t45IpbhpHk80SId5CMxVSZNsn AxlelUNS8C3WrR3RnuNMhnlhETSW9kUFwfMjfdKN/wA3+rwB23HntS1A1bjxHeafpkt3f2FrGRLH FGIb4OhLtjLuUUIo455/Pg6mk389/byNc2ZtpY324EgkRxgEMjgDcvOM4HIIrItPD2oWtpPFA+i2 buytiz03YkoGQVlUudwIPYgj9Ku+H9EbR0uy32ZDcyiQwWkXlQx4UD5VyeTjJPGfSmBs0UUUCCii igAooooAK4L4r/8AIB0v/sIj/wBEzV3tcF8V/wDkA6X/ANhEf+iZqT2Gj0+iiisywrg/BHTxH/2H 73/0Ou8rg/BHTxH/ANh+9/8AQ6qO4mdVRRRVkBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAVz/w6/wCPPxD/ANh+9/8AQ66Cuf8Ah1/x5+If+w/e/wDodTIqJ2VFFFQUcRBq 8+i+H9YurW2F1dNrUsMMBbHmM8wXGfoSfwqXV/HUdqiyWj2YglhtJIp7qTYgM8jAbj2ASN2P4VLo WnJf+fJI5As9eurgIBw5+dQD9C+76qKQ+BkguWuNP1F7aU6g18haFZAhMbIEAPG0eZIR6bvagBtp 4ukWa3ku77RriwkExe5sJjIsflR72yckZxzj0p+h+LrrWo9OT+zxb3dzcXHnQO2TBBE5Xc3+0TsX HqT6VcvPC7asmmjVdRkumsbv7TlYlQSjaQEYD+HnJ9enQ1Z0jw9baRqGp3yO0k9/OZGZh9xeuwe2 Sx+rUAZEXi17vxLdadBqGhwxwXYthDcXGLmTCqXKpn1LAf7tWovE8z6DoeovborarMm1STiOIq0p Y+4iQn61qWGkRWOlzWJdpFnlnllf7pYyuzt06csQPoKx/wDhDWlsFs7rVJZYrezktLLbCqGAOnl7 zj7zheAeBgnjmgCpZ+PPN8P2Go3dqttNJMRdQsxPkxiBrjd7/uwp+rYrXt7zxFMYpJNOtI4bhGKr 5pL2zbSV83IG4E8ELyCR1GSIr3wbpt9qpvJQ4jawexeBeFKsNu7/AHgpZfofaren6ReW9zFNfavP e+RGY4lKCMc4y7gfffjrwBk4AzQBhQeI/EAs57ue30xokvxp8YiaQNJIZlhJ57Bi3/fNWZPFF/8A 2Y+vRWVudDjYklpG8+SINgyqMYxj5gvUjuCcVfi8NQRWem2xuJHWyvGvWJH+ukbzCc+g3ybvwFV1 8J4hj099RlbRopRJHY7F6BtwjZ+pjBxhcA4ABJHFAFRfGcjwawBZqtxbXIhs0ZuJw0xt1b/v6rA4 7bfWrFr4iv7vXpLKO2tNsVw0Uts0xS5jjBIE+1gAyHAIx2YckginjwbZ+VoitcTNJpcnmF+hnJId t31kVX+q1La+HJ476wmu9VlvI9OLG1Eka+ZlkKfvJOr/ACsfTJwTkigBPCf+o1b/ALCt1/6HWZ8Q uvhX/sP2/wD6BJWn4T/1Grf9hW6/9DrI+Jcy2tl4fvJEmaC11qCaZoomkKIEkydqgnHI7d6EB0tF cp/wsjwx/wA/N9/4K7r/AON0f8LI8Mf8/N9/4K7r/wCN1rdEWOrorlP+FkeGP+fm+/8ABXdf/G6P +FkeGP8An5vv/BXdf/G6LoLHV0Vyn/CyPDH/AD833/gruv8A43R/wsjwx/z833/gruv/AI3RdBY6 uiuU/wCFkeGP+fm+/wDBXdf/ABuj/hZHhj/n5vv/AAV3X/xui6Cx1dFcp/wsjwx/z833/gruv/jd H/CyPDH/AD833/gruv8A43RdBY6uiuU/4WR4Y/5+b7/wV3X/AMbpyfETw3JnZc3Zxyd1hOmB/wAC QZ+gyfamtXZCemrOporlP+FkeGP+fm+/8Fd1/wDG6P8AhZHhj/n5vv8AwV3X/wAbpXQ7HV0Vyn/C yPDH/Pzff+Cu6/8AjdH/AAsjwx/z833/AIK7r/43RdBY6uiuU/4WR4Y/5+b7/wAFd1/8bo/4WR4Y /wCfm+/8Fd1/8bougsdXRXKf8LI8Mf8APzff+Cu6/wDjdH/CyPDH/Pzff+Cu6/8AjdF0Fjq6K5T/ AIWR4Y/5+b7/AMFd1/8AG6P+FkeGP+fm+/8ABXdf/G6LoLHV1wXxX/5AOl/9hEf+iZq0v+FkeGP+ fm+/8Fd1/wDG65bxx4k07xRY6bY6OL65uUvfNZP7PnTCiKUE5ZAOpFJtWBI9mooorMsK5O5+GnhS 7vbm8lsLkT3MrTTGPULiMM7HJO1ZABk+grrKKAOO/wCFXeEv+fK9/wDBrdf/AB2j/hV3hL/nyvf/ AAa3X/x2uxooA47/AIVd4S/58r3/AMGt1/8AHaP+FXeEv+fK9/8ABrdf/Ha7GigDjv8AhV3hL/ny vf8Awa3X/wAdo/4Vd4S/58r3/wAGt1/8drsaKAOO/wCFXeEv+fK9/wDBrdf/AB2j/hV3hL/nyvf/ AAa3X/x2uxooA47/AIVd4S/58r3/AMGt1/8AHaP+FXeEv+fK9/8ABrdf/Ha7GigDjv8AhV3hL/ny vf8Awa3X/wAdrnvCngvQtcTUDqFvcyG3uTFF5d7PFhR67HGT7nJr1KuM+H3+r1j/AK/Wren/AAp/ Iyl8cfmO/wCFXeEv+fK9/wDBrdf/AB2j/hV3hL/nyvf/AAa3X/x2uxorA1OO/wCFXeEv+fK9/wDB rdf/AB2j/hV3hL/nyvf/AAa3X/x2uxooA47/AIVd4S/58r3/AMGt1/8AHaP+FXeEv+fK9/8ABrdf /Ha7GigDjv8AhV3hL/nyvf8Awa3X/wAdo/4Vd4S/58r3/wAGt1/8drsaKAOO/wCFXeEv+fK9/wDB rdf/AB2j/hV3hL/nyvf/AAa3X/x2uxooA47/AIVd4S/58r3/AMGt1/8AHa3tC8P6Z4bsGsdKt2gt 2kaVlaV5CXbqSzknn61p0UAFFFFAHP8AhP8A1Grf9hW6/wDQ6wtZ1KbTPE2qeJR5jWelJDYXEQyQ UZTIzAeoaWHn+6Grd8J/6jVv+wrdf+h1p6hf2+ni3E0bOLu4W3G1QfmbOC2T04oA4PTLXSba2mtf GE8QewtYBDBcuVCqYVaSVB1LmUyruGWGwAYqZNEi1abwjBrmnJPfm2knunuU3SmKNNqpIe53TIT/ ALS1v/8ACW6LdLdzJG87WN+tip8tcvM23/VkkZA3HJ44Vj0GaQ+L1ZdLkg0LU511KIPashtwWBTz CCGlBBCjnPHbPSgCr4pDXUdv4W060uHheINeJZlFMVsMqqjcygb2G3Gfuq1YNpq2hatdaVJ4jvLJ Vs9Dhk2XMoUmeU/PgE5LL5OOOfn967FfEtn/AGNdaq9rcxpbzG2eNlUu0gcJtGGIPznb165qCXxN pyO1z/Z9zJYRTeS2pLGhhVg20/xbyobgsFKjnng4AOJ0vVL7S9atdRuUuZRDANLit5GJkd5fMniR iejbBbqSckEnPervhSye/wBWjiv5/tnmtf3l3nJjdmdbZMA9FZY5iB2Brs38Q2MenX2oGGYxWly1 ucKu6WQME+Tnn5jt5xyKji8QyPrkulpoGpCWII0ku632LG7Mquf3ucfI5xjdgdKAOUstE0G1+H+p 66dFs3eWO6uoleIHMe9mhUcdNojqjqmj6NoepaPo/wBm0JRb6eZbkancCBJ5DtRHJ2ncw2y/99E1 6Mmq2hvL6ywUFhFHJM5ACKGDEAe4C5PHQj8Mc+K9PuoxcLpF9cRJBFNcSCKMm2WRQ4DqX3EhSCdg bFAHM28nhEaxdjUzpEEVlYQRwQW84K75N8jmHGGYkPHgqMnt1ru/Di3qeGdLXUjIb0WsfnmQ5fft Gdx9fX3qlba2tzfSLZeH76aOG4a2a8T7OqBkO1sbpA+AQRwvY4roKAOf8J/6jVv+wrdf+h10Fc/4 T/1Grf8AYVuv/Q66CgAooooAKKKKACiiigAooooAKKKKACuM8ff6zQv+v1f6V2dcZ4+/1mhf9fq/ 0rfDfxV/XQyrfAzs6KKKwNQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigArjPh9/q9Y/wCv1q0/FXiC58O2kN1FZLcwu+xyXK7D27HrzXCeEvFN1Z3slla2CTy3 9zvGZCNpP4dB1rso0Zyoya62/A56lSKqJM9booorjOgKKKKACiiigAooooAKKKKACiiigAooooA5 /wAJ/wCo1b/sK3X/AKHUnivSb3WdHS3064jtrtLiKaOd8/u9rgkjA64zx36Go/Cf+o1b/sK3X/od dBQBwsngOeK51Q2M8UNs1l5WnRFm/dzmHyTM5x1CgAYznc2eTXRLoxj1vTJ4/LFlp9nLBGhJ3b2M YB9MBUYf8CrYooA46HwVjT9JEqWp1CK9jvL64Utl2DmVtpxk5kx1xxn6U5PDurHRI/DUhs10lT5c l2srGaWHcTs2bQAxGFLbj1JxzgP0y5vtUsLPXZNb+xrdzqYbRlj8nyy+BGcjcZGXvu4boMDBpaZ4 ua/8VSP/AGjAmlS21x5ET4AXymjAlZuvz7pCOcbVU9SaALlv4f1UwW+l3JtfsEN+b2S4SVjJcHzm mVSm0BfnKkncenvxtafpsttrGrX8zoxu5IxFt6rEkYAU8dd5kP8AwKuMm1fXNL0u+F3f3y6ymnv/ AKLPDE0ck7FUjkgdFA2h2A2tk/MuQDydCH+2lsbk29zriXrbI4I9Ua0USndufytgI37EfG7gZyQQ DgAt6hoOrXB12ygNp9k1l8yXTysJYEMSRMoQIQxwhIO4ctz05beeH9Tn1WGWKGwiME6GHUYpXjnS AMrGFowuHGNy8tjBzjPW/wCGLia4hvPMvbycRTCMw30KpPbttDFGKgKwwysCOzdTW9QBxXhzwvfa ddwTahpWmvP5sk017FqMzOzuWYsIzEF6t0zxXa0UUAc/4T/1Grf9hW6/9DroK5/wn/qNW/7Ct1/6 HXQUAFFFFABRRRQAUUUUAFFFFABRRRQAVxnj7/WaF/1+r/SuzrxTxY2q2GuSWd3fXMyQv5tu0jk4 U9CPft9RXXg6fPU32MMRLlge10VzXgiLUToS3mpXU88tyd6CVydqdvz6/lXS1zzjyScb3saxlzJM KKKKgoKKKKACiiigAooooAKKKKACiiigAqlLrGmW8rRTajaRyKcMjzqCPqCau15f4X8NaDqtx4ju dR0TTbyf+3bxfNuLVJGwH4GWBOKaVxN2PQP7e0f/AKC1j/4EJ/jR/b2j/wDQWsf/AAIT/Guf/wCE I8J/9Cvov/gvi/8AiaP+EI8J/wDQr6L/AOC+L/4mnyi5joP7e0f/AKC1j/4EJ/jR/b2j/wDQWsf/ AAIT/Guf/wCEI8J/9Cvov/gvi/8AiaP+EI8J/wDQr6L/AOC+L/4mjlDmOg/t7R/+gtY/+BCf40f2 9o//AEFrH/wIT/Guf/4Qjwn/ANCvov8A4L4v/iaP+EI8J/8AQr6L/wCC+L/4mjlDmOg/t7R/+gtY /wDgQn+NH9vaP/0FrH/wIT/Guf8A+EI8J/8AQr6L/wCC+L/4mj/hCPCf/Qr6L/4L4v8A4mjlDmOg /t7R/wDoLWP/AIEJ/jR/b2j/APQWsf8AwIT/ABrn/wDhCPCf/Qr6L/4L4v8A4mj/AIQjwn/0K+i/ +C+L/wCJo5Q5jU1W90LVtLuLGbVbHZMhXP2hPlPY9exwa4vwDaafp99d32oX9nHLExghDTqM/wB5 hz07A+5roP8AhCPCf/Qr6L/4L4v/AImj/hCPCf8A0K+i/wDgBF/8TW0KkowcFsyJQjKSk+h0H9va P/0FrH/wIT/Gj+3tH/6C1j/4EJ/jXP8A/CEeE/8AoV9F/wDBfF/8TR/whHhP/oV9F/8ABfF/8TWP KXzHQf29o/8A0FrH/wACE/xo/t7R/wDoLWP/AIEJ/jXP/wDCEeE/+hX0X/wXxf8AxNH/AAhHhP8A 6FfRf/BfF/8AE0cocx0H9vaP/wBBax/8CE/xo/t7R/8AoLWP/gQn+Nc//wAIR4T/AOhX0X/wXxf/ ABNH/CEeE/8AoV9F/wDBfF/8TRyhzHQf29o//QWsf/AhP8aP7e0f/oLWP/gQn+Nc/wD8IR4T/wCh X0X/AMF8X/xNH/CEeE/+hX0X/wAF8X/xNHKHMdB/b2j/APQWsf8AwIT/ABo/t7R/+gtY/wDgQn+N c/8A8IR4T/6FfRf/AAXxf/E0f8IR4T/6FfRf/BfF/wDE0cocx0H9vaP/ANBax/8AAhP8atwXMF1E JbeaOaM8B42DA/iK5T/hCPCf/Qr6L/4L4v8A4mofhlbw2ml65b20McMEWuXiRxxqFVFDgAADgCk1 YadztqKKKQzn/Cf+o1b/ALCt1/6HXQVx3h/X9G086vb3ur2FtMNVuSY5rlEYAvxwTmtn/hLPDf8A 0MGlf+Bsf+NAGxRWP/wlnhv/AKGDSv8AwNj/AMaP+Es8N/8AQwaV/wCBsf8AjQAh8KaKZZX+xt+8 35QTSbFL5DsibtqMcnLKAeTzzVu40bTrqKCKezieKBGjjjI+VUZCjLjoVKnGDxVX/hLPDf8A0MGl f+Bsf+NH/CWeG/8AoYNK/wDA2P8AxoAjbwjor20kEltNIsgRS0l1KzqqMHUK5bcoDAHAIGRT08K6 Qls9v5Vw6M6yAyXkzujrnDIxYsh5PKkdacfFfhwddf0of9vkf+NJ/wAJZ4b/AOhg0r/wNj/xoAvW GnWumQNDaRFFZzI7M5d3Y9WZmJZjwBkknAHpVqsf/hLPDf8A0MGlf+Bsf+NH/CWeG/8AoYNK/wDA 2P8AxoA2KKx/+Es8N/8AQwaV/wCBsf8AjR/wlnhv/oYNK/8AA2P/ABoAr+E/9Rq3/YVuv/Q6m8Te JbfwvZW1zPZ3l21zcraww2aK0jOwJHDMo/hPeqvgy4hurHU57eaOaGTVLlkkjYMrDf1BHBqh8Quv hX/sP2//AKBJQAf8LAm/6ErxT/4DQf8Ax6j/AIWBN/0JXin/AMBoP/j1dDRV8pPMc9/wsCb/AKEr xT/4DQf/AB6j/hYE3/QleKf/AAGg/wDj1dDRRyhzHPf8LAm/6ErxT/4DQf8Ax6j/AIWBN/0JXin/ AMBoP/j1dDRRyhzHPf8ACwJv+hK8U/8AgNB/8eo/4WBN/wBCV4p/8BoP/j1dDRRyhzHPf8LAm/6E rxT/AOA0H/x6j/hYE3/QleKf/AaD/wCPV0NFHKHMc9/wsCb/AKErxT/4DQf/AB6ud8Tat/wkUtlI 3g3xPG0En7wm2hy8XdRiXr6fU16HRVwbhLmi9SZJSVmc4nj6SNFRPBPilVUYAFtBgD/v7Tv+FgTf 9CV4p/8AAaD/AOPV0NFRylXOe/4WBN/0JXin/wABoP8A49R/wsCb/oSvFP8A4DQf/Hq6GijlDmOe /wCFgTf9CV4p/wDAaD/49R/wsCb/AKErxT/4DQf/AB6uhoo5Q5jnv+FgTf8AQleKf/AaD/49R/ws Cb/oSvFP/gNB/wDHq6GijlDmOe/4WBN/0JXin/wGg/8Aj1H/AAsCb/oSvFP/AIDQf/Hq6GijlDmO e/4WBN/0JXin/wABoP8A49UM/wATraxaH+0fDXiGximfy1muLeIJu2lscSk9FPaunrgviv8A8gHS /wDsIj/0TNQ4hc9PoooqCgrg/BHTxH/2H73/ANDrvK4PwR08R/8AYfvf/Q6qO4mdVRRRVkBRRRQA UUUUAFFcrr19PoGqy3UJLf2lbi3t0PK/bFOIx7bw5z7R1n21jpkc2p2mt6jKjaasaW7PdtCUhESH zlwR8xfzMtycjHai4zuqK8luZ9Sv7fT1u42nup7vTxLBJKYQ5a3kLBiAduTyeOtdtpC6jo/mR3Vj cPHd3O6OK3uDcLaJtQHc8hVsFtzYUHHNFwOkorym6kWz0KeaO7Fy11p12EvrW+ctcEQO26eFx8pG 3qD8rccA4qbXdN1Gy8LXN59njsLUQRRtCmoySiVmnhIY5UBMDeCRknf7UrhY9Qorz9vJtbWGNFsb KzuL6GK9ksNTefEWHxucqpjBfYvHUMRxVxxp1nrGn2ek3kzomqRiaESs8cRNvMdqk+uASuTjg4Ge XcDtKK8usrCeH4d3GpvY28MjaUzLeR30jyuxXqUKALkZ6McfrWyTp8767e65fTW13Z3brE0dyyvB EAvlmNAcZYc/dO4kjnpRcDuKKAcjNFAgooooAKKKKACuf+HX/Hn4h/7D97/6HXQVz/w6/wCPPxD/ ANh+9/8AQ6mRUTsqKKKgoheztZHLvbQsx6lkBJpv2Cz/AOfSD/v2KsUUAV/sFn/z6Qf9+xR9gs/+ fSD/AL9irFFAFf7BZ/8APpB/37FH2Cz/AOfSD/v2KsUUAc94es7V49S3W0LY1CcDKA4G7pWz9gs/ +fSD/v2KzfDn+r1P/sIz/wDoVbVaVfjZMPhRX+wWf/PpB/37FH2Cz/59IP8Av2KsUVmUV/sFn/z6 Qf8AfsUfYLP/AJ9IP+/YqxRQA2ONIkCRoqKOiqMCuO+IXXwr/wBh+3/9Akrrbu6gsbWS5uZBHDGM uxBOB+Fcd46uIbuLwnNbypLE2vW5V0YEH5JO4ppPcV+h0tFFFaEBRRRQAUUUUAFQXd5DYwrLOxVG ljiBAz8zuEUf99MKnrN120mvdPiigUM63lrKQSB8qTxux/75UmgZAPFWjnSNQ1T7UfsmnyyQ3LmN gUdOoxjJ6jGOuRirl9qtpp1ml1cO+yRlWNY42d5GPQKqgkn8OxPauGuPB+qvpt/ZpCnk3y3Ms0fm DmVXlMPf+LzIiT28oA9a6G+0rUH08JOF1SMTI62wxBJCoB/1UikfOCV5JHAIyM0gJz4w0gPbxg3b TTSPGIVs5TIjIFLBk27lwHU8joQRTf8AhM9IaZIYPttzK0ZkKQWUrsgDlDuULlSGUjBAPFYUXhrW LzWNOnuJb+3s4ZLkoXuka5hRkjCqzgndllfuxAxk+iXvheex8RpcWVjqlzZ/YvLMlpqIhkaUyvIx cl1LZ3Z/GjUDp7rxJp9m0aSLeNI0SzNHFZyyPEhzguFUleh4PPB9DSXHifSoITIJpJgDEoEELSFz IMptCg5yOeKzra31LSdQu72DS7m7W/ghPltcx+ZDIibdrszYIIwdyljndwe9O68O6pfXLNdIqmS5 s5JXtJjGBsQhyhzuABPHegDoIfEFhKAZPtFt+6lmIuoHhISPZvY7gOB5i/r6Gnafr9jqVz9nh+0J KUMiLcW0kPmIMZZd6jcBkdOmR6isXW/Cs9/EtnazzeUdNu7fz7idpGEkjwsgYkliPkb8Bitiyu9V u7+Pz9LFlbJEfNaaRHd5CRgJsY/KMHJbBPHA5pgatFFFAgooooAKKKKACuC+K/8AyAdL/wCwiP8A 0TNXe1wXxX/5AOl/9hEf+iZqT2Gj0+iiisywrg/BHTxH/wBh+9/9DrvK4PwR08R/9h+9/wDQ6qO4 mdVRRRVkBRRRQAVW1C9i0zTbq/nDGG2heaQIMnaoJOPfAqzWdr9lLqXhzU7CAqJrm0lhj3HA3MhA z7ZNAzLufFunwW7Tajp17bNFBJeRJcRIWdYwNxQhiNwDDjIPNSzarZywvfarod1bJaYaOS7hjdtx IULGEZjuJIAAHJIrG1TwROLS+i0xlk+2abJaMLq5kYwuRwyM24hWIww9lI6Gp4vD9/JaTRCwjs5F khuYnk1Sa7VpIpA6qQ6/KDggkc89DSAu3HifTLdJpr/Tbq2nh8uXy54F3uC4jDqQSDguAecjPvWj qGvWmm3X2edZS+yN8qoIw8ojHf8AvMPwrm9V0LXvElzKdQtrS1SO3kW08qUvhy8TjzD1xmLgqDwT kA4BtXujavrVzNd3NvbWjBbeKOITmTcEuFldidoxwuAOc98UATW2uaRLLNcHRZ4ILi4Nm969vHsl bzDHhirFsFxj5hjkVNZeIrfXIPl0S+ewcuDPNHEYjsJByN5PVSOlZdt4Lms0tbyNhJfQahLcvDJc SNBLG8zMPlPyq6qysCBwy+5NR+H/AAzqek7YpdPiZg82bkarNtw7MQfJ27ejY/WgDRtfEXh1PDlp q9vZiK01KZLVYlt1V3ZnKbWUccfMT7AmpNH1yzvIIvsOgXkNgjSeXP5UKxIU3KSAHyOQR071iw+C NQisrW0Mtv5EC2sypuOFuFMQlI46bYmx6mVulS+H/DOp6Ttil0+JmDzZuRqs23DsxB8nbt6Nj9aA Nq28S6VfaDp91ZW8lxbX+6GG3SNQ2VjdyhViADiNhj1x25qrD4l0y/8AP1C40S7jNjIYBPPBGzeb vCeUm1mO4swA7e9Qaf4TvNPvfDs0U0SxWqIb+EE4aVLZoVkTjr82D6hV9ObUOg3sGiavamGxuXu9 QluVhuCTG8byBtrHHBK55wcHB5oA19M1ZNSM0Ztbm1uICPMguUAYA9DkEqQcHoT0NaFYPh3TLzT5 btpla3tZAggtDdvceWRu3MGb7obK/KOBtz3xW9TAKKKKBBRRRQAV5vpb+JU0vX/7DVTB/bl75pj5 mB39ge2MdOa9Irn/AIdf8efiH/sP3v8A6HTU+RqVrg48ytc0NCOuNoViSbUkwrkzb9+cfxe9aH/E 7/6h/wD4/WlRUynd3sUo2Vrmb/xO/wDqH/8Aj9H/ABO/+of/AOP1pUVPN5By+Zm/8Tv/AKh//j9H /E7/AOof/wCP1pUUc3kHL5mb/wATv/qH/wDj9H/E7/6h/wD4/WlRRzeQcvmYll4ejRZnupZxPNM8 ri2u5o0yxzwAwFWf7DtP+e2of+DCf/4utKim6k31BQiuhm/2Haf89tQ/8GE//wAXR/Ydp/z21D/w YT//ABdaVFLnl3Dlj2M3+w7T/ntqH/gwn/8Ai6P7DtP+e2of+DCf/wCLrSoo55dw5Y9jB1bwzFe6 VcW1vPdCWRNqma+mdB9QWIP5VxWt+FIPDa+GWS5lnml123VyThPuSHhfw69fzr1OuM+IXXwr/wBh +3/9Akq1Wny8l9BezjfmtqdDRRRQIKKKKACiiigDjvEPie40rxI9o2oQWVpFZxXBeTT5bnczPIpy UYbR8q9fWqJ8VaxJqC211MuluthbzvENKmum8yQybgdjfLjYMA88+1dk2lWsmo3F7Ipd7i2W1kRs FCilzjH/AANs1kxeEI7WQSWes6rbMII7clJI23IhYoCWQnjeRn0xnPWkMFvNc1K6vk064sYEsXEH +kW7uZ5fLVyeHGxfnA/iPBPtVTRvFk+sWes3iRRpHbW0M8CHJI3wCQhj3wTjjFX77wrFe7yuqapa tME+0NazLGZ2QABmO3hsAAlduQADwBTH8H2pt1givr63ia2jtZ0gdFE8aDaNw2/KccZTacfhQBhX fjDUw9vGssFsJbuOJpVs5LgqrWYmOEVsn5uM9hTJfGepSJYNFcwLbXd3LHHfJpszCWJYg4ZYd2/7 5ZSc/wAOa6tPDdhFqUd9GJFkjnE6oCNoYQ+SBjHTZ+tVbnwhaT3wu4L6+tJVuHuU8h0wjuu1yAyn G7qR6knuaNQM7/hJb+21fQbeSWK5s7xZftM5tHgYHescZCMcr87qvPXdmsufxxqkmptBG8FrbPqE kEUws5LhvJWFXVtinLbic5HZh6V1Uvhe3uoit5e3t1IbeS3E0jIHVWZWyNqgbgUUg4496gm8GWDX MVzbXV5ZTQuHja3ZPlxEsWAGUjGxRRqBQk8UXtheaX57xXWnyW8015cfZXt3jVZERX2MSQqlvmz2 y3amahreu/Y7S7tLyziSfVX04o9qXwPtMkQfO8fwqvGOTnkZroLbQoorhLi5urm9lSCS33XOw7kd lJBCqAfuj9agg8KabbaTY6ZD5y21ldi7hG/J3iQyAEkcjLH3x3oAy9Q1vWdNv2iurm0gii8tY5Z7 GUQ3WVG4mZWKw/NuADA4wDyDx2FY154bt72a6LXd5Hb3mPtdrG6+XPwFOcqWXKgA7SuRWzTAKKKK BBRRRQAVwXxX/wCQDpf/AGER/wCiZq72uC+K/wDyAdL/AOwiP/RM1J7DR6fRRRWZYVwfgjp4j/7D 97/6HXeV5f4X8S6DpVx4kttR1vTbOf8At28byri6SNsF+DhiDiqjuJnfUVg/8Jv4T/6GjRf/AAYR f/FUf8Jv4T/6GjRf/BhF/wDFVZJvUVg/8Jv4T/6GjRf/AAYRf/FUf8Jv4T/6GjRf/BhF/wDFUAb1 FYP/AAm/hP8A6GjRf/BhF/8AFUf8Jv4T/wCho0X/AMGEX/xVAG9RWD/wm/hP/oaNF/8ABhF/8VR/ wm/hP/oaNF/8GEX/AMVQBvUVg/8ACb+E/wDoaNF/8GEX/wAVR/wm/hP/AKGjRf8AwYRf/FUAb1FY P/Cb+E/+ho0X/wAGEX/xVPk8Y+GIdvneIdKi3DK+ZeRruHqMnke9AjborB/4Tfwn/wBDRov/AIMI v/iqP+E38J/9DRov/gwi/wDiqBm9RWD/AMJv4T/6GjRf/BhF/wDFUf8ACb+E/wDoaNF/8GEX/wAV QBvUVg/8Jv4T/wCho0X/AMGEX/xVH/Cb+E/+ho0X/wAGEX/xVAG9RWD/AMJv4T/6GjRf/BhF/wDF Uf8ACb+E/wDoaNF/8GEX/wAVQBvUVg/8Jv4T/wCho0X/AMGEX/xVH/Cb+E/+ho0X/wAGEX/xVAG9 XP8Aw6/48/EP/Yfvf/Q6d/wm/hP/AKGjRf8AwYRf/FVD8MriG70vXLi2mjmgl1y8eOSNgyupcEEE cEVMho7aiiioKCiiigAooooAKKKKACiiigAooooAKKKKACuM+IXXwr/2H7f/ANAkrs65Lx9p+qXt lo02k6e1/PY6rFdvAsqRlkVXBwXIHVhQBt0Vy/8Abvi3/oQL3/wZWv8A8XR/bvi3/oQL3/wZWv8A 8XWnMiLM6iiuX/t3xb/0IF7/AODK1/8Ai6P7d8W/9CBe/wDgytf/AIujmQWZ1FFcv/bvi3/oQL3/ AMGVr/8AF0f274t/6EC9/wDBla//ABdHMgszqKK5f+3fFv8A0IF7/wCDK1/+Lo/t3xb/ANCBe/8A gytf/i6OZBZnUUVy/wDbvi3/AKEC9/8ABla//F0f274t/wChAvf/AAZWv/xdHMgszqKK5f8At3xb /wBCBe/+DK1/+LqvdeLddsDEL/wfcWpmbZEJL6BvMb+6NhOD9cD3qormdkJ+6rs7CiuX/t3xb/0I F7/4MrX/AOLo/t3xb/0IF7/4MrX/AOLqeZDszqKK5f8At3xb/wBCBe/+DK1/+Lo/t3xb/wBCBe/+ DK1/+Lo5kFmdRRXL/wBu+Lf+hAvf/Bla/wDxdH9u+Lf+hAvf/Bla/wDxdHMgszqKK5f+3fFv/QgX v/gytf8A4uj+3fFv/QgXv/gytf8A4ujmQWZ1FFcv/bvi3/oQL3/wZWv/AMXR/bvi3/oQL3/wZWv/ AMXRzILM6iuC+K//ACAdL/7CI/8ARM1av9u+Lf8AoQL3/wAGVr/8XWF4otPF3iy2sbL/AIRC4sVh uvPaaW/t3GBG64wrk9WFJtWGker0UUVBQVSl0bS5pWll02zkkY5Z3gUkn3OKu0UAZ/8AYOj/APQJ sf8AwHT/AAo/sHR/+gTY/wDgOn+FaFFAGf8A2Do//QJsf/AdP8KP7B0f/oE2P/gOn+FaFFAGf/YO j/8AQJsf/AdP8KP7B0f/AKBNj/4Dp/hWhRQBn/2Do/8A0CbH/wAB0/wo/sHR/wDoE2P/AIDp/hWh RQBn/wBg6P8A9Amx/wDAdP8ACj+wdH/6BNj/AOA6f4VoUUAZ/wDYOj/9Amx/8B0/wrkvAumWF1Hq xuLG2m2XjKvmRK20egyOBXe1xnw+/wBXrH/X61b0/wCFP5GU/jj8zo/7B0f/AKBNj/4Dp/hR/YOj /wDQJsf/AAHT/CtCisDUz/7B0f8A6BNj/wCA6f4Uf2Do/wD0CbH/AMB0/wAK0KKAM/8AsHR/+gTY /wDgOn+FH9g6P/0CbH/wHT/CtCigDP8A7B0f/oE2P/gOn+FH9g6P/wBAmx/8B0/wrQooAz/7B0f/ AKBNj/4Dp/hR/YOj/wDQJsf/AAHT/CtCigDP/sHR/wDoE2P/AIDp/hVu3tre0i8q2gihjznZGgUZ +gqWigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA K4zx9/rNC/6/V/pXZ1xnj7/WaF/1+r/St8N/FX9dDKt8DOzooorA1CiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuM+H3+r1j/AK/Wq741vtX0vS0v9LmCLG2J 1MYbg9DyOx4/GuB8I6rrT6uun6fOsYu5vMmby1bA/ibkeldtGi5UZNNf8Mc1SolUSseyUUUVxHSF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFcT48ljeTQ9siNi9UnDZx0rtq8R8ZaJ/YniCWONcW0372HHQA9R+B4+mK 68FBSqas58TJxhse2JIkmdjq2OuDmnVzXgjRP7G8PxmRcXNziWXPUf3V/AfqTXS1z1IqMmk7m0W3 FNhRRRUFBRRRQAUUUUAFFFFABRRRQAUUUUAFcndfErwrZ31zZy39wZ7aVoZRFYXEgV14I3LGQSPY 11lcH4I6eI/+w/e/+h00ribsW/8AhaPhL/n9vf8AwVXX/wAao/4Wj4S/5/b3/wAFV1/8arfoquUX MYH/AAtHwl/z+3v/AIKrr/41R/wtHwl/z+3v/gquv/jVb9FHKHMYH/C0fCX/AD+3v/gquv8A41R/ wtHwl/z+3v8A4Krr/wCNVv0Ucocxgf8AC0fCX/P7e/8Agquv/jVH/C0fCX/P7e/+Cq6/+NVv0Uco cxgf8LR8Jf8AP7e/+Cq6/wDjVH/C0fCX/P7e/wDgquv/AI1W/RRyhzHN3XxI8G3lrLbT3d60UqFH H9lXXII/65Vy/g3xL4W8Py3s91e3bTu5jiYaZdH90Oc8R8Z447Yr0yirjKUYuCejJaTkpPoYH/C0 fCX/AD+3v/gquv8A41R/wtHwl/z+3v8A4Krr/wCNVv0VHKVzGB/wtHwl/wA/t7/4Krr/AONUf8LR 8Jf8/t7/AOCq6/8AjVb9FHKHMYH/AAtHwl/z+3v/AIKrr/41R/wtHwl/z+3v/gquv/jVb9FHKHMY H/C0fCX/AD+3v/gquv8A41R/wtHwl/z+3v8A4Krr/wCNVv0Ucocxgf8AC0fCX/P7e/8Agquv/jVH /C0fCX/P7e/+Cq6/+NVv0Ucocxgf8LR8Jf8AP7e/+Cq6/wDjVb+h6/pniTTzfaVcGe3EjRFmieMh 16gq4BBH0orn/h1/x5+If+w/e/8AodJqw07nZUUUVIwooooAKKKKACiiigAooooAKKKKACiiigAr m/GWv3+g2Wnf2ZbW093fX8dnGLl2SNSysckqCf4fTvXSVxnxC6+Ff+w/b/8AoElAEf8AaHxE/wCg f4W/8DLj/wCNUf2h8RP+gf4W/wDAy4/+NV0tFacqJuzmv7Q+In/QP8Lf+Blx/wDGqP7Q+In/AED/ AAt/4GXH/wAarpaKOVBdnNf2h8RP+gf4W/8AAy4/+NUf2h8RP+gf4W/8DLj/AONV0tFHKguzmv7Q +In/AED/AAt/4GXH/wAao/tD4if9A/wt/wCBlx/8arpaKOVBdnNf2h8RP+gf4W/8DLj/AONUf2h8 RP8AoH+Fv/Ay4/8AjVdLRRyoLs5r+0PiJ/0D/C3/AIGXH/xqs3VrLxvrRtTeab4YY20okTF5Pz6q f3XQ8Z+ldvRTj7ruhPVWZzX9ofET/oH+Fv8AwMuP/jVH9ofET/oH+Fv/AAMuP/jVdLRS5UO7Oa/t D4if9A/wt/4GXH/xqj+0PiJ/0D/C3/gZcf8Axquloo5UF2c1/aHxE/6B/hb/AMDLj/41R/aHxE/6 B/hb/wADLj/41XS0UcqC7Oa/tD4if9A/wt/4GXH/AMao/tD4if8AQP8AC3/gZcf/ABquloo5UF2c 1/aHxE/6B/hb/wADLj/41R/aHxE/6B/hb/wMuP8A41XS0UcqC7Oa/tD4if8AQP8AC3/gZcf/ABqs 7WPGXjHw2lrc6tpmhPbTzeR/ol1MzhtjMPvIBj5DXbVwXxX/AOQDpf8A2ER/6JmpOKsCZ6fRRRUF BXB+COniP/sP3v8A6HXeVwfgjp4j/wCw/e/+h1UdxM6qiiirICiiigAooooAjSeGSaSFJY2lix5i KwLJnkZHbNU5de0eAQGXVbGMTjMO+4QeYOny88/hWR4jh1C2v0udLimaXUIP7PkeME+QxbMcxA6B N0uT7iq1rFaeHbrV7S60y6nhuPLW1ENm86yQLCiCHKggYKvwxA+bPc0DOku9X02wV2vNRtLZY2VX M0yoFJGQDk8EgEj6VLaXtrfwCezuYbmEkgSQyB1yPccV5sND1yJdNgEUiXUN1p+6YwmVE2W7qxOC NwBIBOeveuysNL1PS7iSWOS0u5L25869kcGAKAqIPLQBsnC9z17+hcC/HrmkSyXKR6rYu9qrPcKt whMSjqW5+UDuTTI/EOiTW8txFrGnvBCAZZVuUKoCcAsc4HPHNcDdWd0dBewsrO/nSPT7qNbW809h LZ5gcBY5goEmW2pj5i2c54q/4l8O6pL4dmvZ7k3l9HbxQQx2tiVZUM0TtlQWZyPLBx9eOaVwOwt9 f0a7gnnttWsJobcAzSR3KMsYOcFiDx0PX0qW21XTr2GOa11C1nikk8tHimVlZ8Z2gg8nAJxXJzyX V7FayyzahqMFpfRTzxSaTLbnywHGVVlHmYco2BkjZ06Vanb+09ZsLyz0q5jhXUImkuZIWjMoEEwy UYBgq7lG4jnOO1O4G1F4l0GeR44db02R0UsypdoSoHUkA8AVYn1bTbW9isrjULSK7lx5cEkyq754 GFJya4230jWY/hpNbzTzTM2lmNLD7KFdH2jAyOSRyMe9Ww32Aa/Z6hpV3qFxe3Tyxqls7JcoyqI1 MgBVdowuWIxtz6UrgdnRRRTEFFFFABRRRQAVz/w6/wCPPxD/ANh+9/8AQ66Cuf8Ah1/x5+If+w/e /wDodTIqJ2VFFFQUFFFFABRRRQAUUUUAFFFFABRRRQAUVS1LV7DR4Vlv7lIEc7VyCST7Ac1l/wDC c+G/+gmv/fp//iauNOcleKbJc4rRs6GuM+IXXwr/ANh+3/8AQJK0v+E58N/9BNf+/T//ABNc14u8 QaVrU/hyLT7tZng1qCaQbWXagVwTkgd2H51Xsan8r+4XtId0dpRRRQIKKKKACiiigAqnqd+NNtUn MZk3XEEGAcY8yVY8/hvz+FXKparYHUrOOASCMrcwT5Izny5Ukx+OzH40DOfPjuBfDmtas9k4bTLi SDyBICZSG2qQccBifwwfStfWNcTSdLguzCHaeRIow8gjRWbpvc8KPfB5wMZNYc/gTzYZYhfgLLFc pIPK4dnaUxsRn+Dz3+pweMVsTaDJHbMtheyJK7hpRdvJcwyAAgp5bPhFO7ouMYHUDFLUClJ4n1Bb ywsF0QC8umlBWS62x7UVG3I4U7wQ4xwOQQelV4vGl1e6j9hstJhMyRM832m9EQRlleIqCFYNyhOe ODUdt4Atjf21zfx6fLBHJNK1iloPs6l0jUBVYkDHl5JxyWPAqTU/BaT6zFe2Nvoy28doLVbW70/z UTDs2VAZQv3qNQNKTXb2S6a0sNLS6ubeKOS7H2oIkZcZCKxHzNgZ6KMEcjNVrvxZJFvSDTiZfMt4 1S4l8nmVS3zfKdpGMEc1JHoepWNxLcabc6fDLdQxJOjWreWrou0MgDjAxgbSew5HeKXwet03+mXa 3aNLbSSieEN5vlIVO4dDuznpxRqBNL4mbT4w+rWkVuv2W4ui1vcecNsRjGAdq5JMnT29+LthqGoz XfkX+ktaB4zJHIkwlXgjKuQBtbngDIODzxVPUfCVjfILeJIrWz+xXNr5MEQUKZWjbeAOAQY89OSa t2VprAvY5tQ1CB4oo2QRW0BQSscfO2WbGMcAep5NMDVooooEFFFFABRRRQAVwXxX/wCQDpf/AGER /wCiZq72uC+K/wDyAdL/AOwiP/RM1J7DRH4ctdb8UvfSnxJfWphkHyqzMDuz0AYAdOlb3/CFa3/0 OWofk/8A8cqn8L/9Xq3/AF0T/wBmr0GurEVpwquMdvRGNGnGUE3+bOK/4QrW/wDoctQ/J/8A45VX wEjR2utRNIXaHVriF3P/AC0ZSAXPfLHk5Jrv64PwR08R/wDYfvf/AEOsHWnPR/kjT2cY6o6qiiip GFFFFABRRSNnadpAbHBIyKAOZm8XeVPrS/Y/3djbyzW0hfi5MI/ejp8u1iq9+p9Ko2fj6MxrLeLp 8kRtJLpzp179oaFUUMQ6lV25zgHPXA71PdeAbOXSLe2t5xb3scbxy3oiy0wkjZJNwz/EWLfUD0q5 L4RtJY4oxIY0ayaxvFRABcxFcDPoynkHnGSO9LUZHf69rWk6Re6jqGj2yQwWslwPKvN+wqAdj5Qd eeV3dPxpmoeN9OhM/wDZlxZ6l5NhPdv9nuVbaYzGAp25xu3nn/Zp994a1HVbC4s9Q11pIntnt0EV v5eSwxvkG4h2HbG0cnjpi7rvh9db3brkw7rKez4TdxKYzu69vL6e9PUCo+s60vixdGFhp5iaJrkS m6cN5QcL02fe5BxnHvWbpPjs3mnDUruTRktltWupYLe/Mlyihd2PLKjnt1rpDpIPiVNZ845Wza18 rb6uG3Z/DGKxtO8I3VppC6Ndaja3GmfZmtXRLLy5WQqV+/vPPfOO1LUDQjvPEbAiTSLJGePdGRel lRuPlk+QHoTyu7kfjWVZeK9UkhsJ7zTbNIbzUWsF8m6ZmUq0iliCgGMx8c962bPTNTjvYZr7WDcx wIUjjih8reTxuk+Yhz6YCgZPHTFY+GANFiso7srPb3r3sFwYg2yRpXk5XPI+cqeRkelMCrrni6TS 717VIbRSt1Fb+dd3PlRjfE8mWO04xsx+NUpvHkixwqkelBnvfspuX1A/ZD+5MuRLs5PG3GOD3rUT ws8t3Fe398txdC9W7kKwbI2CxPGqBSxwAHJySTn9IbjwjKJ4m0/UI7aGC7a6t7eW282OItGyOoG4 fKSxYDsc+vC1A2tHvpNR05LmR7KQsxAayuPOjIBxw2BzV+qmm293bWvl3lxBPIGJDQweSoHpt3N7 85q3TAKKKKBBRRRQAVz/AMOv+PPxD/2H73/0Ougrn/h1/wAefiH/ALD97/6HUyKidlRRRUFBRRRQ AUUUUAFFFFABRRRQAUUUUAee/E9QzaMrDIMkgP8A45XQ/wDCDeG/+gYv/f1//iq5/wCJv+s0X/rp J/7JXoNdc5yjRhyu2/5nPGMZVJXXY57/AIQbw3/0DF/7+v8A/FVzXi7w/pWiz+HJdPtFhefWoIZD uZtyFXJGCT3UflXo1cZ8QuvhX/sP2/8A6BJWPtqn8z+819nDsjoaKKKBBRRRQAUUUUAc54wvJls7 bTbW4ube4vpCvn2sTySQxoNzOAgJ67U/4GK5mfXLzVtW02dbbVpQNLkmuLKxuDAyTJKFfKll3YIZ dvJPpXopt4TcrcmJDOiGNZMfMFJBIB9CVH5CoYdMsbe7e7htII7h926VUAZtxBOT7kA/hRYZx+hP ea+8NtfatceVHYR3MTWlxsabzJJACzKASUVEU9BkkkcipdN1fVBrl3DZk65CljanzvOWJd26YFgO mW284/u10c/h/SLmJIptNtmRGZlHlgYLHLY+p5Pr3q3BZWttIXt7eKJjGkRKIF+RM7V47DJwO2aL AcJps13qmhTm51C+DRaHY3SvFcvG3mmKUsxKkE5IBPrgelV0S88jwrHHLrV6b3T5bq4jh1Jkdn2w c7mccDc3Gf4ulegQ6bY28RjitIURoVgKqgAMaghVPsATge9V7vw/o9/DbQ3em2s0VsuyBHjBEa4A wvoPlH5ClYDDtrafUNWOl3FzqdjBa2MU6Q/bCZnd3kDF5AxLbdgGMkfNz2qreWYub7w4ya5qFwl5 M8M81vdyRJMEgkOQqthTuQE4xnn1rpJPDmjS2kNq+mWxggyIk8sDYCckD0BPUd6u/YrUfZsW8QFr /qAEA8r5Svy+nykjjsadgOOW9vYfCmvs13cedBqkkMTtKS6p5qhVBJz0I/OsyK+1P7c7o+pxyTa3 LbxXkt3utQq3DDyzHuOMopUfKMnHPSu7l0LSp9RXUJdPt3u1YMJWjBO4fdb3IwMHqO1TNptk9pLa taQm3ldpHjKDazFtxYj13c59aVgOP8LC8vbv7VcW+tSD7bdL9pbUf3GFmkVR5XmZwAAMbe1d1WTH 4X0GK9+2x6RZpc+YZfNWEBt5OS2fXPNa1NAFFFFAgooooAK4L4r/APIB0v8A7CI/9EzV3tcF8V/+ QDpf/YRH/omak9hovfC//V6t/wBdE/8AZq9Brz74X/6vVv8Aron/ALNXoNa4v+NL+uhGH/hoK4Pw R08R/wDYfvf/AEOu8ry3Rtbl8O3mv2t54f8AEMjS6xdTxyW2lyyxujPlSGAwc1hHc1Z6BRXK/wDC dQ/9C34p/wDBLP8A4Uf8J1D/ANC34p/8Es/+FXdE2Oqorlf+E6h/6FvxT/4JZ/8ACj/hOof+hb8U /wDgln/wougsdVRXK/8ACdQ/9C34p/8ABLP/AIUf8J1D/wBC34p/8Es/+FF0FjqqK5X/AITqH/oW /FP/AIJZ/wDCj/hOof8AoW/FP/gln/wougsdVRXK/wDCdQ/9C34p/wDBLP8A4Uf8J1D/ANC34p/8 Es/+FF0FjqqK5X/hOof+hb8U/wDgln/wo/4TqH/oW/FP/gln/wAKLoLHVUVyv/CdQ/8AQt+Kf/BL P/hR/wAJ1D/0Lfin/wAEs/8AhRdBY6qiuV/4TqH/AKFvxT/4JZ/8KP8AhOof+hb8U/8Agln/AMKL oLHVUVyv/CdQ/wDQt+Kf/BLP/hR/wnUP/Qt+Kf8AwSz/AOFF0FjqqK5X/hOof+hb8U/+CWf/AAo/ 4TqH/oW/FP8A4JZ/8KLoLHVUVyv/AAnUP/Qt+Kf/AASz/wCFH/CdQ/8AQt+Kf/BLP/hRdBY6quf+ HX/Hn4h/7D97/wCh1V/4TqH/AKFvxT/4JZ/8KtfDdLj+yNWuLiyu7P7Vq91cRx3cDRSbGYFSVYZF TJjR2VFFFQUFFFFABRRRQAUUUUAFFFFABRRRQB598Tf9Zov/AF0k/wDZK9Brz74m/wCs0X/rpJ/7 JXoNdNX+DT+f5mMP4k/kFcZ8QuvhX/sP2/8A6BJXZ1zfjLQL/XrLTv7MubaC7sb+O8jNyjPGxVWG CFIP8Xr2rmNjSormv7P+In/QQ8Lf+Adx/wDHaP7P+In/AEEPC3/gHcf/AB2tOZE2Z0tFc1/Z/wAR P+gh4W/8A7j/AOO0f2f8RP8AoIeFv/AO4/8AjtHMgszpaK5r+z/iJ/0EPC3/AIB3H/x2j+z/AIif 9BDwt/4B3H/x2jmQWZ0tFc1/Z/xE/wCgh4W/8A7j/wCO0f2f8RP+gh4W/wDAO4/+O0cyCzOlormv 7P8AiJ/0EPC3/gHcf/HaP7P+In/QQ8Lf+Adx/wDHaOZBZnS0VzX9n/ET/oIeFv8AwDuP/jtH9n/E T/oIeFv/AADuP/jtHMgszpaK5r+z/iJ/0EPC3/gHcf8Ax2j+z/iJ/wBBDwt/4B3H/wAdo5kFmdLR XNf2f8RP+gh4W/8AAO4/+O0f2f8AET/oIeFv/AO4/wDjtHMgszpaK5r+z/iJ/wBBDwt/4B3H/wAd o/s/4if9BDwt/wCAdx/8do5kFmdLRXNf2f8AET/oIeFv/AO4/wDjtH9n/ET/AKCHhb/wDuP/AI7R zILM6Wiua/s/4if9BDwt/wCAdx/8do/s/wCIn/QQ8Lf+Adx/8do5kFmdLXBfFf8A5AOl/wDYRH/o matj+z/iJ/0EPC3/AIB3H/x2s7V/BvjHxIlrbavqehJawTefm0tZlctsZR95yMfPSclYEif4X/6v Vv8Aron/ALNXoNeffC//AFerf9dE/wDZq9BrbF/xpf10M8P/AA0FFFFcxsFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAeffE3/AFmi/wDXST/2SvQa8++Jv+s0X/rpJ/7JXoNdNX+DT+f5mMP4k/kFFFFcxsFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeffC//AFerf9dE/wDZq9Br z74X/wCr1b/ron/s1eg104v+NL+uhjh/4aCiiiuY2CiiigAooooAK5278e+ErC7mtLvxHpsNxC5S SN7hQyMOoIzwa6KvPvBdtBKfEbSQRu39v3vLICfv00ribsbP/CyPBX/Q0aV/4Er/AI0f8LI8Ff8A Q0aV/wCBK/41f+w2n/PrB/37FH2G0/59YP8Av2KrlFzFD/hZHgr/AKGjSv8AwJX/ABo/4WR4K/6G jSv/AAJX/Gr/ANhtP+fWD/v2KPsNp/z6wf8AfsUcocxQ/wCFkeCv+ho0r/wJX/Gj/hZHgr/oaNK/ 8CV/xq/9htP+fWD/AL9ij7Daf8+sH/fsUcocxQ/4WR4K/wCho0r/AMCV/wAaP+FkeCv+ho0r/wAC V/xq/wDYbT/n1g/79ij7Daf8+sH/AH7FHKHMUP8AhZHgr/oaNK/8CV/xo/4WR4K/6GjSv/Alf8av /YbT/n1g/wC/Yo+w2n/PrB/37FHKHMUP+FkeCv8AoaNK/wDAlf8AGj/hZHgr/oaNK/8AAlf8av8A 2G0/59YP+/Yo+w2n/PrB/wB+xRyhzFD/AIWR4K/6GjSv/Alf8aP+FkeCv+ho0r/wJX/Gr/2G0/59 YP8Av2KPsNp/z6wf9+xRyhzFD/hZHgr/AKGjSv8AwJX/ABo/4WR4K/6GjSv/AAJX/Gr/ANhtP+fW D/v2KPsNp/z6wf8AfsUcocxQ/wCFkeCv+ho0r/wJX/GtvS9X07W7MXml3sF5bFivmwOGXI6jIqn9 htP+fWD/AL9isX4cKqWPiBVACjXrwAAcD5xUtWGnc7OiiikMKKKKACiiigAooooAKKKKACiiigDz 74m/6zRf+ukn/sleg1598Tf9Zov/AF0k/wDZK9Brpq/wafz/ADMYfxJ/IKKKK5jYKKKKACiiigAr n/FviO48N2NjJaacL+6vbxLOKFp/JG5gxyW2tgfL6V0FcZ8QuvhX/sP2/wD6BJQA3/hJfGv/AEJV l/4Ox/8AGaP+El8a/wDQlWX/AIOx/wDGa6OitOVE3Oc/4SXxr/0JVl/4Ox/8Zo/4SXxr/wBCVZf+ Dsf/ABmujoo5UFznP+El8a/9CVZf+Dsf/GaP+El8a/8AQlWX/g7H/wAZro6KOVBc5z/hJfGv/QlW X/g7H/xmj/hJfGv/AEJVl/4Ox/8AGa6OijlQXOc/4SXxr/0JVl/4Ox/8Zo/4SXxr/wBCVZf+Dsf/ ABmujoo5UFznP+El8a/9CVZf+Dsf/GaP+El8a/8AQlWX/g7H/wAZro6KOVBc5z/hJfGv/QlWX/g7 H/xmj/hJfGv/AEJVl/4Ox/8AGa6OijlQXOc/4SXxr/0JVl/4Ox/8Zo/4SXxr/wBCVZf+Dsf/ABmu joo5UFznP+El8a/9CVZf+Dsf/Gao6l8QPEGhi2l1jwlBb2s8vkiSHVRKwbYzD5fKH90967GuC+K/ /IB0v/sIj/0TNScVYLl74X/6vVv+uif+zV6DXknhBvEcIv8A+w4LaVPMAlMpHBGcY5HvXTfafiB/ z46f/wB9D/4quvE0eaq3zL7zno1LQSsztaK4r7T8QP8Anx0//vof/FUfafiB/wA+On/99D/4qsPY P+Zfea+18n9x2tFcV9p+IH/Pjp//AH0P/iqPtPxA/wCfHT/++h/8VR7B/wAy+8Pa+T+47Wq93e2t hEst3OkMbMEDucDJ6c9q5L7T8QP+fHT/APvof/FVheLZvFcmibdYtrSO081fmiIzu5x/EauGG5pJ OS+8mVaybSf3HqKsGUMpBBGQR3rhPBHTxH/2H73/ANDrl/CN54nScRaOsk0APzxy8wj6k9PwOa6b wH5hg8QGUKJf7dvN4U5AbeM49s0qtD2MrXuOnV9pG9jrKKKKzKIftdv9sFn9oi+1GPzfJ3jfszjd t64zxmqdz4h0Wz/4+tY0+D52j/e3KL8643LyeoyMjtkVzniG2vbXxb/b1pYT3LWVrAAkSEmZWeZX Qe4Dq+P9kVhW+l6lomuROXvocTXZkvINPkuRI7x2pLbVU8M6yHPsaVxnoMmv6NDbQXMur2CQXGRD K1ygWXHB2nODj2qWfV9MtbqG1uNRtIbiYAxRSTqryAnA2gnJ/CuVvXZp7e/E2qRzvaeSbv8Asl5E nG9sxyQbN6c4I+7uDdTxWbPb3MGnSqun3NreXFnCj6f9ha5tborEAE3KMx4OV5cYxnnrRcD0Q3EA uRbGaMXDIZBFuG4qCAWx1xkgZ9xVZtY0xNQGntqNoL09LYzr5h/4DnNcleW2svq8viRLH/j1uljS LDGZrdN0ciqoXkEvI49cJ7VWdtSsdBXSodP8/VY7p5JI7jTZZY7qQy7llWZWCJ2bLHI4BAxRcDsY /EWiS3v2KPWdPe7LmPyFukL7h/DtznPtT77XNI0uVYtQ1SytJGXcqXFwkZI6ZAJHFcr4XmvLKcWt xcajEhvbn/RTpEuzDzSFT52zGDuDZzjmtO70/U7jxjcT2d49lF/Z8KGX7OJFdhJKduTxkZB/EUwO ht7q3u4zJbTxTIDtLRuGAPpkVVTW9JknngTVLJprdS00a3CFogOpYZ4A75rn7W4ljj13TI0vra+u rq4NtN9imMallwr+YF2AZ75qssMV/pmg6Rb6RdW89pLEZhLavGluigiUbyNrbhuT5Sc7s9OaLgdk Lu2a4W3FxEZ2j81Yw43FMgbgOuMkDPvVUa7pDXMNuNVsTPOA0MQuE3SA9Cozk59q4RNM1uPTG1GO 1uP7TssaTFlDukhWNoxIOMlTK4kJ/urnpVq8sH02a6stMtbw5lh22E9kZra52LGqOJgo8vhFB3Nh SucequB6DRRRTEFc/wDDr/jz8Q/9h+9/9DroK5/4df8AHn4h/wCw/e/+h1MionZUUUVBQUUUUAFF FFABRRRQAUUUUAFFFFAHn3xN/wBZov8A10k/9kr0GuA+JkSynRkbIDSupI64O2r3/CuNL/6CGqf9 /l/+JrskoOjDmdt+nmc6clUlZX2Oxorjv+FcaX/0ENU/7/L/APE0f8K40v8A6CGqf9/l/wDiay5K X8/4f8Evmqfy/idjRXHf8K40v/oIap/3+X/4mj/hXGl/9BDVP+/y/wDxNHJS/n/D/ghzVP5fxOxo rjv+FcaX/wBBDVP+/wAv/wATR/wrjS/+ghqn/f5f/iaOSl/P+H/BDmqfy/iTf8J3p1vrd1pt+jWx hlKLN95G+vcVU8eTRXEfhOWCRJI2163KujAg/JJ0IrkH8Falea9d2thDIbWKUoLm4OBge+OT9BWj rPhVPDaeGSLyaeWXXbcOCcRj5JDwvrx1ravSoxScZa9v62M6U6km1JaHoVFFFc5qVdTvV03Sry/d C620DzFQcFgqk4/SsZvGFqum6Nd/Z5S+p3KWwhyN0LFtrFvZW+U+5Fa2sWTalol/YI4R7m2khVm6 AspGT+dYB8HyfbnmW6TyVuYJ7ePaf3WJEkmH/A2jB9jQMsaZ4nu7/S49Vl0Z4NOe3Nz5wnV2CBS3 3AMk+1NHi/ytMk1G70m5htfIE8MqSRyJIpZVClgdqtlh1OMZOcKcUPD/AIQvNFtoIEt9Dgmjt2h/ tC2tf9JztID5IwTnBIPBqaHwtqCXc15C2l6fcNAYm+x2x2XLFlYtKh4xhWXHJw5+alqBqpr7xaff XWo6dPZi0hE5O5ZElUgkbGHDH5cY68j1FMXxKkmm2M8NlPJeXjvElmGUMkibvMDEkABSrAn6YBJA rKh8GStJIH+x2NncTQtPZ6eGRGWPcwYEYw7OUyQBwmMk81OPCdxZakb3TLqNTFMZ4Eui8vMibZlZ id2G2owOTgg8EUagWZ/Et3Cba3bRLgX1xcm3WB5VVTiMyblfowwpHrnIq/Lqk9poN3qV9YmB7aKS VoBKHJCqT1HHOK5J/AFzJOt240yU/aVm+wTo8tuoEcidWyWOZM5wOg4rok0WdvCl9pBg06zaeGWK NbKMpEm9SM49ckk0ACa/ex/ZmvtIa2juZo4Y2Fwr5LZ7D6Va1HWHtb2Ows7KS9vXjM3lq6oEQEDc zMeMk4AGScH0JrPuvCsFvY266HZ6dZ3MVxFO7LAI1lKZxu2DJ6n8zTzpusjUI9WV7D7d5Jt5ofnE Uke7cpDckMCT2IIY0wGp4wtWW88y1uIXtLaWeWOTG4NEcOnBIyMoQQSCHFMn8aW0Fla3BtJi08Hm NHuUeU5lSII5JAHzuRknHyNUMnhCWYW00t4hu2vjdXrqhCyISpMSjJwP3UQ5PIU+tSL4XubeXWJr W8hDXkqtFHND5kYj3NI8bg9Qzyy8jkAj0xS1A2dMv5r5JRc2E1nNEwBVyGVwRkFHHDDn8CD+N+sP w7ob6O145jtbZLhlK2dmCIYsDBIBx8zdyABwOO53KYBXBfFf/kA6X/2ER/6Jmrva4L4r/wDIB0v/ ALCI/wDRM1J7AjT+Gn+q1b/r4H9a7yuD+Gn+q1b/AK+B/Wu8rTF/xn/XQih/DQUUUVzmwUUUUAFV NR0y01W3W3vYvNiVw+wkgEjpnFW6KabTuhNJ6MZDDFbxLFBGkcajCoigAfQCuG8EdPEf/Yfvf/Q6 7yuD8EdPEf8A2H73/wBDpx3B7HVUUUVZAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFc/wDD r/jz8Q/9h+9/9DroK5/4df8AHn4h/wCw/e/+h1MionZUUUVBQUUUUAFFFFABRRRQAUUUUAFFFFAH B/Ef/W6J/wBfDf8Astd5XB/Ef/W6J/18N/7LXeV0VP4MPn+ZjD+JL5BRRRXObBRRRQAUUUUAFcZ8 QuvhX/sP2/8A6BJXZ1xXxJZ4bLQLxba5nitNZhnmFvC0rKgSQE7VBOOR+dCA6OiuU/4WDpP/AD5a 5/4KLj/4ij/hYOk/8+Wuf+Ci4/8AiK1uiLHV0Vyn/CwdJ/58tc/8FFx/8RR/wsHSf+fLXP8AwUXH /wARRdBY6uiuU/4WDpP/AD5a5/4KLj/4ij/hYOk/8+Wuf+Ci4/8AiKLoLHV0Vyn/AAsHSf8Any1z /wAFFx/8RR/wsHSf+fLXP/BRcf8AxFF0Fjq6K5T/AIWDpP8Az5a5/wCCi4/+Io/4WDpP/Plrn/go uP8A4ii6Cx1dFcp/wsHSf+fLXP8AwUXH/wARR/wsHSf+fLXP/BRcf/EUXQWOrorlP+Fg6T/z5a5/ 4KLj/wCIo/4WDpP/AD5a5/4KLj/4ii6Cx1dFcp/wsHSf+fLXP/BRcf8AxFH/AAsHSf8Any1z/wAF Fx/8RRdBY6uuC+K//IB0v/sIj/0TNWl/wsHSf+fLXP8AwUXH/wARXM+Ndcj8U2WnWOlabrEk6Xnm sJNNmjAURSDOWUDqwpNqwJHT/DT/AFWrf9fA/rXeVwfw0/1Wrf8AXwP613laYv8AjP8AroRQ/hoK KKK5zYKKKKACiiigArlbv4beEb69uLy40dWuLiRpZXE8q7nY5JwGA5NdVXAQeJ/GOrXuqf2Rp2hC zs76azU3d1MsjGNsEkKhHP1oAv8A/CrPBn/QG/8AJmb/AOLo/wCFWeDP+gN/5Mzf/F1B/aHxE/6B /hb/AMDLj/41R/aHxE/6B/hb/wADLj/41TsxXRP/AMKs8Gf9Ab/yZm/+Lo/4VZ4M/wCgN/5Mzf8A xdQf2h8RP+gf4W/8DLj/AONUf2h8RP8AoH+Fv/Ay4/8AjVFmF0T/APCrPBn/AEBv/Jmb/wCLo/4V Z4M/6A3/AJMzf/F1B/aHxE/6B/hb/wADLj/41R/aHxE/6B/hb/wMuP8A41RZhdE//CrPBn/QG/8A Jmb/AOLo/wCFWeDP+gN/5Mzf/F1B/aHxE/6B/hb/AMDLj/41R/aHxE/6B/hb/wADLj/41RZhdE// AAqzwZ/0Bv8AyZm/+Lo/4VZ4M/6A3/kzN/8AF1B/aHxE/wCgf4W/8DLj/wCNUf2h8RP+gf4W/wDA y4/+NUWYXRP/AMKs8Gf9Ab/yZm/+Lo/4VZ4M/wCgN/5Mzf8AxdQf2h8RP+gf4W/8DLj/AONUf2h8 RP8AoH+Fv/Ay4/8AjVFmF0T/APCrPBn/AEBv/Jmb/wCLo/4VZ4M/6A3/AJMzf/F1B/aHxE/6B/hb /wADLj/41R/aHxE/6B/hb/wMuP8A41RZhdE//CrPBn/QG/8AJmb/AOLo/wCFWeDP+gN/5Mzf/F1B /aHxE/6B/hb/AMDLj/41R/aHxE/6B/hb/wADLj/41RZhdE//AAqzwZ/0Bv8AyZm/+Lrf0XQtM8O2 BsdJtRbWxcyFAzNlj1OSSa5n+0PiJ/0D/C3/AIGXH/xqtXwbr17r+mXcmo21vBd2l9NZyLbuzRkx nGQWAOPqKLDOiooopAFFFFABRRRQAUUUUAFFFFABRRRQBwfxH/1uif8AXw3/ALLXeVwfxH/1uif9 fDf+y13ldFT+DD5/mYw/iS+QUUUVzmwUUUUAFFFFABRRXF/EdrhrLQbSC+vLNbvWIbeaSznaGQoU kJG5TnsPyoA7SiuD/wCEFh/6GTxT/wCDqf8Axo/4QWH/AKGTxT/4Op/8arlYrneUVwf/AAgsP/Qy eKf/AAdT/wCNH/CCw/8AQyeKf/B1P/jRysLneUVwf/CCw/8AQyeKf/B1P/jR/wAILD/0Mnin/wAH U/8AjRysLneUVwf/AAgsP/QyeKf/AAdT/wCNH/CCw/8AQyeKf/B1P/jRysLneUVwf/CCw/8AQyeK f/B1P/jR/wAILD/0Mnin/wAHU/8AjRysLneUVwf/AAgsP/QyeKf/AAdT/wCNH/CCw/8AQyeKf/B1 P/jRysLneUVwf/CCw/8AQyeKf/B1P/jR/wAILD/0Mnin/wAHU/8AjRysLneUVwf/AAgsP/QyeKf/ AAdT/wCNH/CCw/8AQyeKf/B1P/jRysLneUVwf/CCw/8AQyeKf/B1P/jXNeM9LufCtlp99p3iLxC0 sl55LLcapLIhUxSH7pOOqilysLnS/DT/AFWrf9fA/rXeVwPw2ljji1be6rmcdTj1ruvtEH/PaP8A 76FdGKX75/10MqH8NElFR/aIP+e0f/fQo+0Qf89o/wDvoVz2ZtckoqP7RB/z2j/76FH2iD/ntH/3 0KLMLklFR/aIP+e0f/fQrG8S+IRoWlreQrFcESqrR78ZBznBHSnGEpPlRMpKKuzdrg/BHTxH/wBh +9/9Drd0TxjpOt7Y4pvJuT/ywm4Yn2PQ/hWF4I6eI/8AsP3v/odVyShK0lYXMpK6OqorI1/WJtIj sRbWsdzPeXa2qLJMYlBZWOSwVj/D6d6yr3xm+mSCC+0tkuEukinWKXeqQtHJJ5ynaCwAifIwDwfb LuB1lFczqHi9LSWeOOG3IS7S2See58qE7oRKGZ9p2jnaODkketXxrUsfhy61W5sXV7eORzDDIJBI Eyco2BuBA4JA69KLga9FcnL4wuYdIuL82NjNGjQiKW21ESQOZJRHhpNgKldwJ+UjHenweMGOoC0u LS2ba8Alns7szxxrKXRSTsXneqjBxw2c8EUXA6miqNnqH2y/v7dIsRWjrEZd335CoZhj0AZOfUkd qz/D3iQ6/c38Ys/JS1kKb/M3HcHdSjjA2uNoJUFsBhzzQBvUVzE3jKKCTxBC9mwm0mKSaMF8LdKk au2044ILKCOcblPOcC9N4gjh8SxaQYCUdADcbxhZWDMsZHqVRznt8v8AeFAGzRXIWXjK8u4LS4Om WqxXlw9tCFvi0gcFwC6+WMKShyQWIBzg0258YarZ2Oq3dxo1iI9OuFtpNuosdzt5eCMwj5cSjJ68 Hii4HY0VhaR4gbUNTl0+aK0EyQCffZXX2iPBYrgtsXB44GOefSli8Reboaal9lxvvxZ+X5nTN19n 3Zx/wLGPbPegDcormbDxVNf3ciR2MBhSSWNwl4GnhKbuZYto2A7f7xPzLxzUnh3xFd67HbTtb6ZF DPAs+yHUTLMgIBAZPLUDrg88e9AHRVz/AMOv+PPxD/2H73/0Ougrn/h1/wAefiH/ALD97/6HUyHE 7KiiioKCiiigAooooAKKKKACiiigAooooA4P4j/63RP+vhv/AGWu8rgfiY4iGjysCVSZicf8BNWf +Fn6J/z66h/37T/4uux0p1KMOVX3/M51OMakuZ9jtaK4r/hZ+if8+uof9+0/+Lo/4Wfon/PrqH/f tP8A4usvqtb+Uv29PudrRXFf8LP0T/n11D/v2n/xdH/Cz9E/59dQ/wC/af8AxdH1Wt/KHt6fc7Wi uK/4Wfon/PrqH/ftP/i6P+Fn6J/z66h/37T/AOLo+q1v5Q9vT7na1xnxC6+Ff+w/b/8AoElch/wn eo2ut3V1ZSu9lLKXW3uBkAH6H5fwNX9c8V2/iRfDKx28sE8Wu27SKwyv3JBw3fr04P5VdTC1Ka5n sTCvCbt1PQaKK89E95Do/iDW01O9F3Z6nOsMbTM8TqsmFi8s5GDnbxg8jHSsjQ9CorzqXWtTsbO4 W5u5WivdYZLOfJzGVvdjQE+hRSR7bx2FXoJ7621mC7uru7kt575o0u7e5WW1kVnZUiMRIKEfKu5Q eV5PJouB29Fcf4kGoSancSW893LbwWyny9Pu1jltn+YmR42IEgI24BOPlPHNc/f6teyza3fW8uqS Rr5C215HdeXb25e3iZWeInhdzbidpwCc0XA9Qorj5by/ikuPDsl25v7i7TyZlbawt5AXdgc5G3ZM q+mE9aZ471G9gWC202S4EscUlzceQ+wxRAbRKSOW2swbYAd2057ZLgdnRXL6/qE9/wCFLG60i+kt nvLm0ENyEwcPKoyVPUEHkdwaypvFV051kDzIb+O0tbUWqhn8m7eSdWKqBlhgK/AyyqDRcDvaK80l 1e8uZtD00NrE8kF5cW08cMhtp50WMvE7b2Tqu0nJGTnrV7ULDUk0a0nvb3Vbed9ThgRBelXFvJcK u1/LbaW2seQScY54ouB3tFeYalcXmn6r4iWNtbmgsFhSGdNQOy23RKdzqzZYZO4na2Bk12F9NewX 3hdJLnJluGjuWjO1JT9mlbp6blyB7Ci4G/RXE382oXupajbWt48ix6lj7JHd+RLLGLWElY37bXfc RkZyeexzTd3t7qenWKf25diO3vBNBHeLbzI6TRhQ7CQK+1W25BOc565ouFj0iuC+K/8AyAdL/wCw iP8A0TNXaadGYtOt0ZJ0YIMpcS+ZIp9GbJyffJri/iv/AMgHS/8AsIj/ANEzUnsC3F8K+FdL1w6n JeJIWiumRNj7cCui/wCFc+H/APnncf8Af01B8Pv9XrH/AF+tXZ10YivUjUaUmZUqcHBNo5P/AIVz 4f8A+edx/wB/TR/wrnw//wA87j/v6a6yisfrFX+ZmnsafY5P/hXPh/8A553H/f00f8K58P8A/PO4 /wC/prrKKPrFX+Zh7Gn2OT/4Vz4f/wCedx/39NY3ibwHZ2mlK+kWtzLdtKqhQxbg5z/+uvRaKqOK qxad7ilQg1ax5tonwzc7ZtZn2jr9nhPP4t/h+dW/AcaQweIIoxhI9dvEUE54DgDk9a76uD8EdPEf /Yfvf/Q6U686sryYRpxgvdNPX9Hm1eOxNtdR209ndrdI0kJlUlVYYKhlP8Xr2qtD4blOpw6neXyT Xi3AlkKQlEZVhliVFUsSoHms2STk5/DoKKko5W08ITaUt2umamEjmufNSC4g82JY/LCeURuBKjaN pyMcDkDm/p/h9tP0W7soLvyZrmR5fNtohGkLtj/Vpk7QMA4yckk9626KLAclP4Me/eea9u7MTzeS rm1svKSQJMsp3qXbcTswDngE8HNXn8LQD+1IbeVbex1CHD20cYAjmxjzUweDjGRjqoOQc536KLAZ un6T9i0Y2Mlw8ksgdprhBsZ5HJLOBzt5Y4HOOB2rF0XwbLpGs22ofb4GENsLVoYbUxLIoGA5G8jz OFG7HQYx6dZRRYDmNX8Gxatpuq2zXjwzXtw08c6J80BaJYmXr8wKgg9MhvbNOufB8Nyl1O11INSl u/tUd182ImVh5Y2bsEKqqvuAema6WiiwGH4f8LafoNsgS3tpbxWkZrwW6rI29y2CeTwDjr2qG+8K rfadrFm13hdSvUuifKzs2iIbcZ5z5XXj73tz0VFAGVZaJFpur3F1ZMkFrcxjzbRI8KZR0kHPB28E Y5wp4wc0R4bu1YWq6jENKF99uEItv3u7zvO2b92Nu/n7ucce9dHRQBzL+F7q5vbaW71C3mS1dnhl +yYucEMArS78EYbnCjdj83+HvDt5oUdrAbjS5IYIBCWi04xTOAoAJfzSM8An5efaujoosAVz/wAO v+PPxD/2H73/ANDroK5/4df8efiH/sP3v/odTIcTsqKKKgoKKKKACiiigAooooAKKKKACiiigDjP H3+s0L/r9X+ldnXGePv9ZoX/AF+r/Suzrep/Ch8/zMofHL5BRRRWBqFFFFABRRRQByJ8A2V1rl1q WoytOJpS6wL8qge56n9Kq+OraC0i8JwW0KQxLr9vhEUAD5JK7iuM+IXXwr/2H7f/ANAkrSVWc7KT IUIx2R0NZaeHNEj1A6gulWYvDIZTN5K7t5Od2fX3rUopgVX02xktxbvaQvCJvP2MgI8zfv3Y9d3z Z9ahj0PSotQN/Hp9st0WLmURjO49W/3j3PU1oUUAUL7RNL1OZJr3T7e4kVdoaSME7c52n1Gex4qc WNoFuF+zQ7bn/XjYMSfKF+b1+UAfQVYooArR6fZxTQzJbRLLDF5MbhRuSPj5QfTgce1MvtJ0/UzG b6yguTHnYZYw2AcZHPY4GR0OBVyigCrHpljDaR2kVnAlvHIJEiVAFRg24EDsd3NB02xa9+2G0hNz lW83YN2VDKDn1Adh9GNWqKAKraZYtqC35tIDeKABPsG8cEdevRiPxqWe3huUVJ4kkVXWRQwzhlIK n6ggGpaKBEAsrUPcOLeLdc4887B+9wNo3evHHNRT6VYXOnpp81nDJaRhVSFkG1Qv3cemO2OlXKKB mafD2jnT0sP7NtvsqNvWMRgBW/vDuG5PPXmo5/C+g3MNvDNpFk8duGWFTCuEDHLY9MkZPqa1qKAI bS0t7C1S2tIUhgjGEjjGFXnPAriPiv8A8gHS/wDsIj/0TNXe1wXxX/5AOl/9hEf+iZqT2Bbm58Pv 9XrH/X61dnXGfD7/AFesf9frV2dXif4rJo/AgooorA1CiiigAooooAK8v0jVb3w5e69a3PhnX7jz tXuriOW1svMjdHfKkHI7V6hRTTsBwn/Cayf9Cl4p/wDBd/8AZUf8JrJ/0KXin/wXf/ZV3dFPmYrI 4T/hNZP+hS8U/wDgu/8AsqP+E1k/6FLxT/4Lv/sq7uijmYWRwn/Cayf9Cl4p/wDBd/8AZUf8JrJ/ 0KXin/wXf/ZV3dFHMwsjhP8AhNZP+hS8U/8Agu/+yo/4TWT/AKFLxT/4Lv8A7Ku7oo5mFkcJ/wAJ rJ/0KXin/wAF3/2VH/Cayf8AQpeKf/Bd/wDZV3dFHMwsjhP+E1k/6FLxT/4Lv/sqP+E1k/6FLxT/ AOC7/wCyru6KOZhZHCf8JrJ/0KXin/wXf/ZUf8JrJ/0KXin/AMF3/wBlXd0UczCyOE/4TWT/AKFL xT/4Lv8A7Kj/AITWT/oUvFP/AILv/sq7uijmYWRwn/Cayf8AQpeKf/Bd/wDZVb+HUF3HpGqz3djc 2Ru9WubmOK5j2SbHYFSR2rsKKTdwSCiiikMKKKKACiiigAooooAKKKKACiiigDjPH3+s0L/r9X+l dnXGePv9ZoX/AF+r/Suzrep/Ch8/zMofHL5BRRRWBqFFFFABRRRQAVz3i7w5c+JLKxjs9SXT7myv UvIpmt/OG5VYYK7l/vevauhooA4r/hGvGv8A0Otl/wCCQf8Ax6j/AIRrxr/0Otl/4JB/8ertaKd2 KxxX/CNeNf8AodbL/wAEg/8Aj1H/AAjXjX/odbL/AMEg/wDj1drRRdhY4r/hGvGv/Q62X/gkH/x6 j/hGvGv/AEOtl/4JB/8AHq7Wii7CxxX/AAjXjX/odbL/AMEg/wDj1H/CNeNf+h1sv/BIP/j1drRR dhY4r/hGvGv/AEOtl/4JB/8AHqP+Ea8a/wDQ62X/AIJB/wDHq7Wii7CxxX/CNeNf+h1sv/BIP/j1 H/CNeNf+h1sv/BIP/j1drRRdhY4r/hGvGv8A0Otl/wCCQf8Ax6j/AIRrxr/0Otl/4JB/8ertaKLs LHFf8I141/6HWy/8Eg/+PUf8I141/wCh1sv/AASD/wCPV2tFF2Fjiv8AhGvGv/Q62X/gkH/x6qGp /D7xFrq28OreLree3gl84JFpIjJbYyjnzT/eNeiUUXY7HGfD7/V6x/1+tXZ1xnw+/wBXrH/X61dn W2J/isyo/Agrnrzx54T0+8ltLvxFpsNxCxSSJ7hQyMOoIzwa6GvPvBdtBKfEbSQRu39v3vLICfv1 ilc0bsbP/CyPBX/Q0aV/4Er/AI0f8LI8Ff8AQ0aV/wCBK/41f+w2n/PrB/37FH2G0/59YP8Av2Kr lFzFD/hZHgr/AKGjSv8AwJX/ABo/4WR4K/6GjSv/AAJX/Gr/ANhtP+fWD/v2KPsNp/z6wf8AfsUc ocxQ/wCFkeCv+ho0r/wJX/Gj/hZHgr/oaNK/8CV/xq/9htP+fWD/AL9ij7Daf8+sH/fsUcocxQ/4 WR4K/wCho0r/AMCV/wAaP+FkeCv+ho0r/wACV/xq/wDYbT/n1g/79ij7Daf8+sH/AH7FHKHMUP8A hZHgr/oaNK/8CV/xo/4WR4K/6GjSv/Alf8av/YbT/n1g/wC/Yo+w2n/PrB/37FHKHMUP+FkeCv8A oaNK/wDAlf8AGj/hZHgr/oaNK/8AAlf8av8A2G0/59YP+/Yo+w2n/PrB/wB+xRyhzFD/AIWR4K/6 GjSv/Alf8aP+FkeCv+ho0r/wJX/Gr/2G0/59YP8Av2KPsNp/z6wf9+xRyhzFD/hZHgr/AKGjSv8A wJX/ABo/4WR4K/6GjSv/AAJX/Gr/ANhtP+fWD/v2KPsNp/z6wf8AfsUcocxQ/wCFkeCv+ho0r/wJ X/GtzS9W07WrIXml3sF5bFiolgcOuR1GR3ql9htP+fWD/v2KxfhwqpY+IFUAKNevAABwPnFS1Yad zs6KKKQwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOM8ff6zQv+v1f6V2dcZ4+/1mhf 9fq/0rs63qfwofP8zKHxy+QVgeLPEcvhuyspbfTmv7i8vEtIoBMIsswYgliMD7tb9cZ8QuvhX/sP 2/8A6BJWBqN/4Srxd/0Iv/lWh/wo/wCEq8Xf9CL/AOVaH/CujqjqOsWGlGJbucrJLny40RpHbHUh VBJAyMnGBkVfKibsyv8AhKvF3/Qi/wDlWh/wo/4Srxd/0Iv/AJVof8Ks3XizRbOG3mkunaG4AMUk NvJKjZO0DcikZzxjrmrNrrunXkV1JDO2LVQ84eJ0aMFdwyGAPTmjlQXZm/8ACVeLv+hF/wDKtD/h R/wlXi7/AKEX/wAq0P8AhVhvFmjrcNAs9xJIoQt5VnNIBuUMuSqEDKsD+NPTxTo8l29sLpg6Tm3L NDIqeYG27Q5XaTu44PWjlQXZU/4Srxd/0Iv/AJVof8KP+Eq8Xf8AQi/+VaH/AArWv9WsdLVmvLgR BYJLg5Un92m0O3A7b19+ajuNe0u1t7Oea8RY70FrdsE+YAhfIwP7oJo5UF2Zv/CVeLv+hF/8q0P+ FH/CVeLv+hF/8q0P+FWIfF2hT27TrfbYxCbj97C8ZaMYyyhlBYcjpnrVvU9bsNHMC3ssitcMViWO F5WcgZOAgJ6UcqC7Mz/hKvF3/Qi/+VaH/Cj/AISrxd/0Iv8A5Vof8K0IfEOmT3NnbLcOs96rtbxy wvGzhPvcMARj369qgufFmiWlw9vJeM0yTG3aOKGSRhIEDlcKp6KQaOVBdlb/AISrxd/0Iv8A5Vof 8KP+Eq8Xf9CL/wCVaH/CtG317Tbq4tbdLgrPdI8kEU0bxO6oQGIVgDxkfz6VWvPFujWJQT3MoDyN EpS1lcF1doyuVUjO5WGPajlQXZX/AOEq8Xf9CL/5Vof8KP8AhKvF3/Qi/wDlWh/wqwfFujidoBLd NKoXcqWM7bdyhgDhODhgcHnmnp4p0eS7e2F0wdJzblmhkVPMDbdocrtJ3ccHrRyoLsqf8JV4u/6E X/yrQ/4UweN9btdS0y31Xwm1lBf3aWizjUI5drsCR8qjP8Jrpq5bxn/x+eFP+w/b/wDoElDirBc7 uiiioKCiiigAooooA4z4ff6vWP8Ar9ausury2so1kup0hRmCBnOBk9BmuG07T/F+gz3yafYWU0M8 7SbpX5PpjDCqHi+58Uy6Ht1exsobXzVO+Fstu5x/Ea7pUVVq3UlZ+ZyxqOFPZ6HpwIIBBBB6EVwn gjp4j/7D97/6HXL+EdR8TJOINIWS5gB+aKXmJfxP3fwP5103gMyGDxAZVVZTrt4XCnIDbxkA9xnv WVWg6MrXuaQq+0jexvazPc2uh6hcWSb7uK2keFMZ3OFJUY784rmPItbcaFNp+p3l2+pyCKXfeySC 5iMbF3xuwu3AOVxg4HfFdrWLeyaR4clju00xRc303kZtLZfMlYhn5xgnhSazLOL1Cz/s7R/E91Z3 F8Li01OGC3L38xCofs528seCWbnBPJqx4qvta826iuo4rYm3ttkVrfyFWzdxqctsQqSCRkA8Gumk 1vQnsrhnt2cvdCGW1azbzZJ9oZQYyuSdqhgemADnApLjV9BvbSZ7208yQMltJaT2haZmb5lTYQSw OMjqOCc8HCA5vUbO5itdNt4bPY9xqaI0EeuTyCVRBMcGQjKDIzgdcVv+DZLl4dSFyXiaO62fYpbl 7h7XCKMGR+SG++McYbg0umXXhuK4t4LPS4rK6muTF5P2MROkqxM4LDH9zdgjP3iPWrM3iDSLLWfs zqY7ue6WzaQRfekEauoZvTEigZ7nFAHF6TrV3pl3p+qXNzcT2Y0OzjmiaRmBkeOR1fB43Fo9mepM gqtpI1afWreyuje6lNDFeNKseoyW48xbrbuBDDjkgDsD7V2V74g0DTrybTvsZlnge2t2hgtg3zMG eFQPYISPTjFTR63pFteWRmsJbC5vpnt4WmtgjMxw5yR0DMfxb3oAq+G3vbLVbuy1a+82eGxtM75S w3EzZwTjJwFBOMnGTWH4RS5ntUv54md99yftTavMXOGkA/cH5ewHX3rb1rU/Douppr/QjfSW0y2r 3H2FZdjnbtXceesi49zTGuvDFlcC4Ph3y7lE+0TMmmAyW6ksN7lRkZ2seMnAzigDl7TVNTHhPR9M N7cfaYLi0uZpzKxeW3d4ioLdfvTbeeoiatDwilzPapfzxM777k/am1eYucNIB+4Py9gOvvXbTHS7 e3t3MEDRzGGCEJGDuGcxgD0Xlh6AE1haZd+E7qe2u49Fhs5LgNLBcTWCxh8KWLB8Y6ZPJBwDQBja LeXv2fwpoupXNxN9rAmjuDIwaeFrSUsjMDncjFec5wUPXOKs1p9m0HxHNBPetNDrMdpFv1CYARGW D5MljjO4jd1wTXWjxNoiWyzNazwwW1u9zavJaFFaNEJJiyBzszxwSM9s1Na32j6p5thLpzQ/aUN1 JBeWm1ZgCoLnI2sQSmeSeVoA5jUbO5itdNt4bPY9xqaI0EeuTyCVRBMcGQjKDIzgdcVv+DZLl4dS FyXiaO62fYpbl7h7XCKMGR+SG++McYbg1oW9loen3kFva6fZW8swM0RhgRQxQYyCB1Af8icd60lg iSaSZIkWWQAO4UBmx0ye+MmnYCSuf+HX/Hn4h/7D97/6HXQV5r4Z1DxjbT+IY9D03SLiz/tu7O+7 uXR92/kYCkY6VMho9corz0eK/GWnarpMOt6Po8dnf3qWe+1unZ1ZgxBwVA/hNehVBQUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHGePv9ZoX/X6v9K7OsfxB4dtfEVtFDcyyxeU+9WiIznG O4rC/wCFbWX/AEFNQ/77X/CulOnKnGMpWav0MbTjNtK9y4PHWmw61daZfhrZoZSizH5kb69x/L3q l49ljnTwnLDIskba9blXQ5BGyToRXHN4M1K8127tLGKR7eGUp9pnOF49T3P0rS1jwqPDcfhkm9ln kl123DrnEY+SQ5C+vHWtK9KjBJxlr2/rYilUqSbUloeh1gXiXOn+Jm1RbCa8gns0tj5BUvCyuzfd JHDbxyOhQZ45rfornNjjzo+ovoUYa2KTza3FfNbhlPkx/aVcgkHBO0FjjuTjPeK68M3t5q/ii586 9gS6WMWywThVmIhCnI+vHOKnXX9ZSzu9VlNjJY2+oyWzW6QOsoiWYxbg5cgtjBxtAPI4pz+INWfR 7rxDAtmdLt2lb7M0bec8MbEM/mbgASFZgu09hnnhAZFjp+r6Zql27W+uqkht2UWBtjG223iRt3mH OdykcelTf8I1qi28s8j3U9udYmuZdLLIEliNwzqynAOfuvgtg4IxzW5aajrOpiS+sRY/YlungW3k RvMkVJDGz+ZuwpyrEDaeAOeeGwa/dy+HI9RaOHzm1MWZUKduw3nkZ69dvP17Y4oAg8X6Ve6kZPsk BlzpN5AMMB+8doCq8nvsb8qxb3wxq0ssEK2xeDTZZYLIiQcwyRynPJ6DMMY/3CehqY+O9QXwdqmo G2tjqlrKywwgNskTBcPjOcBFkzz1jPSrWneKbu+1u5tZNS0+3WHUZLVbY2EryOivtH7wSBQT67cD 0o0Arv4Svf8AhBo457m9vNRh0owQ2sphVYnaMBgNirk8Y+Yn+tP186pq+oaPd2+ka1aLZTSmRovs 4mw0ZUFdzsvXg57GpLLxlfXWlp5sFvBqL3cUagglHhkm8sSKMg8cgjPUehFWYdU8SCXXQzafeNpf yJBBZvG9w5hWRQCZW28uBjBzjtmgCheaZql3c6dqcNpfvPp1vK8ZvXiE0kgljOw7Dt+dBIoPvzWU /hrWbHVILtbe+P8Apr3E0tg8Rk3SWyh2USHGDIXHPauv8Pa3Pqd3cQTXllciNFb91BJbSxkkgq8U jFscDDcdxiqF34nvmvLVLea0tre4luwsklrJcHbAyR/dR15LFznpjb3zQBE+h3msXljPIl/BJbWk whu73yjNHP5sbIxEZwRgMMDGVyD1pI9J1efw3pKXNkI71Nc+2XESSAiNDdPISDnkYYH1qxpfiPU9 f+zQWDWMEv2Y3E88kTSoQZXjQKgdSM+WxOWyvAIJziDUPFGo2OrjT7y+0fTJFsUnIuI3lEsheRcK Q64HyKcYJ+agBk1rqdp4q1e5SHXfIuLiKSP7B9nMbgQxqd3mfNnKkcelRf8ACNaotvLPI91PbnWJ rmXSyyBJYjcM6spwDn7r4LYOCMc1u6X4oTUpYLRrOeG9aKNp0wCLeR4hJtYZD4AIG7bjPGc8VpaP ftqWlxXEiBJtzxTKOiyIxRwPbcpxQBerlvGf/H54U/7D9v8A+gSV1NcX8RbUXsPhy2M08Il1uBfM t5THIvyScqw5B96HsCPRqK4P/hBYf+hk8U/+Dqf/ABq18OJLg6Rq1vcXt3efZdXureKS7maWTYrA KCzcmoasUmdlRRRSGFFFFABVPUtLtNWtlt72LzYQ4fZkgEjpnFXKKabTuhNJ6Mjgt4bWFYbeJIol GFRFAA/AVw/gjp4j/wCw/e/+h13lcH4I6eI/+w/e/wDodOO4PY6qsPxHaX07aTcWFsLl7O+E7xGQ JlfKkTgn3cVuUVZJxx0TVm1ceImt4BeLchxYiXP7ryTGRvxjfklvTAxnnNOm0fVrrWU8RG2ijuYZ IvKsmm5aJUmQ7mAwHPnsR1HygZ5OOvoosBzN1Brd7PZanJYQq1jdmWGyEw8xozE8bbn+7uy+QBxh evPGZdeGdU1aaa7njitJbi4luFUS7zbt5MSREkcEhogxxx25ruaKLAedah4S1ee4ivTbCSeSW1ub lIboxNvVrkuquCCNomjUHPQe1ay+HpdRNnHeWE0NqhnWVLi/a5fDoACHYkjkcc8EZrr6KLAcZD4d 1gaFqNpdyxT3U2qwXCyg48yKN4PmYdmKxkkevSrXiDSr271FriDT/NcwCOC6tb1rWaJsniQg4dOc jg4Ofl5zXU0UWAwL+C5ik8OT3cola1uQLmVVwC7wvGGx2BdwPbdXL2ng3U7nTLLTp7d7PyraW3nu ZL5p1ZXheMiOIkhTllORjAUjvivR6KLAcnqEHiLU9AutKNha2++xmgkcz7xK5iKqI+mF3HJLAHAx jnIde+ELc6PKiC7ursxogM167FQHRyEL7lHKKcEYO0A8V1VFFgOQ0+wvILjQ7OeKNZLe7uLttiKp WEpIg37AF3FpVPAAOCexrr6KKACuT8B/6nxD/wBh68/9DrrK5PwH/qfEP/YevP8A0OgB/jP/AI/P Cn/Yft//AECSu7rhPGf/AB+eFP8AsP2//oEld3US3KQUUUVIwooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACuM+IXXwr/wBh+3/9Akrs64r4ks8NnoF2ttczx2uswzTC3haVlQJJk7VBOOR+ dCA6OiuU/wCFg6T/AM+Wuf8AgouP/iKii+JegT7/ACYdXk8tzG+zS5ztYdVOE4I9K1uiLGgnhOBX kWTUb6Wyku2u2sn8ryjIZPM6hA5G7nBbHY5FPl8LW8olg+3Xi6dNKZZbBSnlMS25hkrvClskqGxy R04qh/wsTRv+fTWv/BTcf/EUf8LE0b/n01r/AMFNx/8AEUtANCbwzDLJKgv72OxmmM8tkjJ5bOW3 NyV3gFskgMAST6nJ/wAIzCbkH7fe/YxdfbPsWU8vzd/mZzt343/NjdjPtxWf/wALE0b/AJ9Na/8A BTcf/EUf8LE0b/n01r/wU3H/AMRRoBZfwTpjwNE0l1tazlsyd4+6+75umNwEjgH0c8Gp7Xw21jdT y2ms6jDFPcvdSW4WAoWZssMmMtg/71Z//CxNG/59Na/8FNx/8RR/wsTRv+fTWv8AwU3H/wARRoBf fwlpsltpkLNPnTZxPBIHAYndv2txypIGR/sj0q02hWr/ANq5knH9pMHlKvtKERqgKEcjhAe/NY3/ AAsTRv8An01r/wAFNx/8RR/wsTRv+fTWv/BTcf8AxFGgGxYaKLS+N7cX11fXQi8lJLgRgomckAIq jkgZJz0HSqEXhd1dGTUbm0e2nuWt5bbyyTHM4kZWEiMOGyBjsB6mq3/CxNG/59Na/wDBTcf/ABFH /CxNG/59Na/8FNx/8RRoBdi8Kw2pjkstQvba6AcS3KGNnnDuXbeGQqfmLEYAxk44OKtaZ4ftNKuj cQSTtI1usDGV924B3fcTjO4tIxPb0ArI/wCFiaN/z6a1/wCCm4/+Io/4WJo3/PprX/gpuP8A4ijQ DTuvDdtdazDqk1xcPJBIJYojs2qwXbw23eB3KhsZ5xyc2tHsZNO0yOCZ1ecs80zJ90ySOXfHtuY4 9qwv+FiaN/z6a1/4Kbj/AOIo/wCFiaN/z6a1/wCCm4/+Ip6AdZXJ+OP9d4W/7D0H/oElH/CxNG/5 9Na/8FNx/wDEVja34ktvEepeHLbT7LVS8OsQzyGbT5olVArgksygdxSbA9Frn/h1/wAefiH/ALD9 7/6HXQV574T8Z6XoT+IbO7g1J5f7cvHzb2E0y4L/AN5VIz7UpDR6pRXJWnxG0C71C1sgupQS3Uoh hNxp00Ss5zhdzKBk4NdbUFBRRRQAUUUUAFcndfDXwpd3tzeS2FwJ7mVppTFqFxGGdjknasgAyfQV 1lFAHlHjHwH4f0o6B9ihvYvterw203/EyuW3xsrkrzIccqORzWz/AMK18L/8+t7/AODS6/8AjlW/ iF18K/8AYft//QJK6GriSzk/+Fa+F/8An1vf/Bpdf/HKP+Fa+F/+fW9/8Gl1/wDHK6yiqsI5P/hW vhf/AJ9b3/waXX/xyj/hWvhf/n1vf/Bpdf8AxyusoosByf8AwrXwv/z63v8A4NLr/wCOUf8ACtfC /wDz63v/AINLr/45XWUUWA5P/hWvhf8A59b3/wAGl1/8co/4Vr4X/wCfW9/8Gl1/8crrKKLAcn/w rXwv/wA+t7/4NLr/AOOUf8K18L/8+t7/AODS6/8AjldZRRYDk/8AhWvhf/n1vf8AwaXX/wAco/4V r4X/AOfW9/8ABpdf/HK6yiiwHJ/8K18L/wDPre/+DS6/+OUf8K18L/8APre/+DS6/wDjldZRRYDk /wDhWvhf/n1vf/Bpdf8AxytvRdC07w9Ymy0yAwwGRpSGleQlm6ksxJP51o0UAcX8RbKDUYPDlncq zQza3AjhJGQkFJOjKQR+Bqz/AMK38Mf8+19/4NLr/wCOUnjj/XeFv+w9B/6BJXWUrAc58M4/s+j6 xao8rQ22s3cMIllaQqisABuYknHua7WuN+HX/Hn4h/7D97/6HXZVmWFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFcH4I6eI/+w/e/+h13lcH4I6eI/wDsP3v/AKHVR3EzqqKKKsgK KKKACiiigAooooAKKKKACiiigAooooAKKKKACuT8B/6nxD/2Hrz/ANDrrK5PwH/qfEP/AGHrz/0O gY/xn/x+eFP+w/b/APoEld3XCeM/+Pzwp/2H7f8A9Akru6iW5SCiiipGFFFFABRRRQBxvxFiuzZ6 FdWthd332PWIbiWK0j8yTYEkBIH4j86rf8JrJ/0KXin/AMF3/wBlXd0U07CaPOrb4jW15532bw54 kl8mVoZNlhnY6nDKfm6ip/8AhOv+pV8T/wDgv/8Asqd4I6eI/wDsP3v/AKHXVVaJOT/4Tr/qVfE/ /gv/APsqP+E6/wCpV8T/APgv/wDsq6yimByf/Cdf9Sr4n/8ABf8A/ZUf8J1/1Kvif/wX/wD2VdZR QByf/Cdf9Sr4n/8ABf8A/ZUf8J1/1Kvif/wX/wD2VdZRQByf/Cdf9Sr4n/8ABf8A/ZUf8J1/1Kvi f/wX/wD2VdZRQByf/Cdf9Sr4n/8ABf8A/ZUf8J1/1Kvif/wX/wD2VdZRQByf/Cdf9Sr4n/8ABf8A /ZUf8J1/1Kvif/wX/wD2VdZRQByf/Cdf9Sr4n/8ABf8A/ZUf8J1/1Kvif/wX/wD2VdZRQB57q+sX PiTUvD1vbeHddtxb6tFcyy3VnsRUVXBJOT/eFehUUUAc/wDDr/jz8Q/9h+9/9Drsq434df8AHn4h /wCw/e/+h12VZFhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXnq+DPFun6hqb 6P4nsbe0vb2W8EU2n+YyNIckbt/NehUUAeVa/H4/0I6Xu8TaZN9vvo7IY0zbsLKx3ff5+7096v8A 9j/ED/oa9L/8Ff8A9nWn8QuvhX/sP2//AKBJXQ1cdSWcX/Y/xA/6GvS//BX/APZ0f2P8QP8Aoa9L /wDBX/8AZ12lFVYRxf8AY/xA/wChr0v/AMFf/wBnR/Y/xA/6GvS//BX/APZ12lFFgOL/ALH+IH/Q 16X/AOCv/wCzo/sf4gf9DXpf/gr/APs67SiiwHF/2P8AED/oa9L/APBX/wDZ0f2P8QP+hr0v/wAF f/2ddpRRYDi/7H+IH/Q16X/4K/8A7Oj+x/iB/wBDXpf/AIK//s67SiiwHF/2P8QP+hr0v/wV/wD2 dH9j/ED/AKGvS/8AwV//AGddpRRYDi/7H+IH/Q16X/4K/wD7Oj+x/iB/0Nel/wDgr/8As67SiiwH F/2P8QP+hr0v/wAFf/2da3hPQbrQNNuYr69S8urq8lu5ZY4vLXc5yQFya3qKLAct4z/4/PCn/Yft /wD0CSu7rhPGf/H54U/7D9v/AOgSV3dRLcpBRRRUjCiiigAooooAKKKKAOD8EdPEf/Yfvf8A0Ouq ryTUpdV0TxBrEGl65eWsE1/NcNEsUDgO7ZOC8ZP61B/b3if/AKGe+/8AAe1/+M1akibHsVFeO/29 4n/6Ge+/8B7X/wCM0f294n/6Ge+/8B7X/wCM0cyCx7FRXjv9veJ/+hnvv/Ae1/8AjNH9veJ/+hnv v/Ae1/8AjNHMgsexUV47/b3if/oZ77/wHtf/AIzR/b3if/oZ77/wHtf/AIzRzILHsVFeO/294n/6 Ge+/8B7X/wCM0f294n/6Ge+/8B7X/wCM0cyCx7FRXjv9veJ/+hnvv/Ae1/8AjNH9veJ/+hnvv/Ae 1/8AjNHMgsexUV47/b3if/oZ77/wHtf/AIzR/b3if/oZ77/wHtf/AIzRzILHsVFeO/294n/6Ge+/ 8B7X/wCM0f294n/6Ge+/8B7X/wCM0cyCx7FRXjv9veJ/+hnvv/Ae1/8AjNH9veJ/+hnvv/Ae1/8A jNHMgsehfDr/AI8/EP8A2H73/wBDrsq474a2pt/DU8jzyzzXN7NcSySBQWdiCThQAOfQV2NQUFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHFfEaWOFPC8krrHGuvW5ZmOABs k6mtT+29J/6Cll/4EJ/jWtqOl6fq9sLbU7C1vbcMH8q5hWRdw6HDAjPJrK/4QTwf/wBCpof/AILo f/iaadhNXE/tvSf+gpZf+BCf40f23pP/AEFLL/wIT/Gl/wCEE8H/APQqaH/4Lof/AImj/hBPB/8A 0Kmh/wDguh/+JquYXKJ/bek/9BSy/wDAhP8AGj+29J/6Cll/4EJ/jS/8IJ4P/wChU0P/AMF0P/xN H/CCeD/+hU0P/wAF0P8A8TRzByif23pP/QUsv/AhP8aP7b0n/oKWX/gQn+NL/wAIJ4P/AOhU0P8A 8F0P/wATR/wgng//AKFTQ/8AwXQ//E0cwcon9t6T/wBBSy/8CE/xo/tvSf8AoKWX/gQn+NL/AMIJ 4P8A+hU0P/wXQ/8AxNH/AAgng/8A6FTQ/wDwXQ//ABNHMHKJ/bek/wDQUsv/AAIT/Gj+29J/6Cll /wCBCf40v/CCeD/+hU0P/wAF0P8A8TR/wgng/wD6FTQ//BdD/wDE0cwcon9t6T/0FLL/AMCE/wAa P7b0n/oKWX/gQn+NL/wgng//AKFTQ/8AwXQ//E0f8IJ4P/6FTQ//AAXQ/wDxNHMHKJ/bek/9BSy/ 8CE/xo/tvSf+gpZf+BCf40v/AAgng/8A6FTQ/wDwXQ//ABNH/CCeD/8AoVND/wDBdD/8TRzByif2 3pP/AEFLL/wIT/Gj+29J/wCgpZf+BCf40v8Awgng/wD6FTQ//BdD/wDE0f8ACCeD/wDoVND/APBd D/8AE0cwcpzXivUbG71DwpHbXtvM412AlY5VY42Sc4Br0WsW18H+GLC6jurPw5pFvcRHdHLDYxo6 H1BC5FbVS3caVgooopDP/9k= ------_=_NextPart_001_01C75213.70BD4C5E Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C75213.70BD4C5E-- From speermint-bounces@ietf.org Fri Feb 16 19:41:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDd4-0004Ev-Dc; Fri, 16 Feb 2007 19:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIDd3-0004Ep-0h for speermint@ietf.org; Fri, 16 Feb 2007 19:40:41 -0500 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIDd1-0007IK-KC for speermint@ietf.org; Fri, 16 Feb 2007 19:40:40 -0500 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l1H0ea3Y011400; Sat, 17 Feb 2007 00:40:36 GMT Subject: Re: [Speermint] [wg-business] Updating Milestones From: Daryl Malas <daryl@level3.net> To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain Date: Fri, 16 Feb 2007 17:50:01 -0700 Message-Id: <1171673401.17141.49.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org This makes sense to me. Thanks for working to put this together. --Daryl On Fri, 2007-02-16 at 16:43 -0500, Livingood, Jason wrote: > All - > > We have been spending a lot of time thinking about our current > milestones and, philosophically, about how documents and work flows > through the group. I am a bit of a visual thinker so I created the 3 > variations of document flows to facilitate discussion with our ADs and > other stakeholders. Those different flows are attached, for your > information. > > I believe we have concluded this now and we are close to an update of > our milestones (see below). In addition, if you open those flow charts, > we have concluded that Document Flow v1-C will satisfy the various > interested parties in SPEERMINT and will be using that as a guide. > > A few key points: > > * This recognizes that VoIP (TN-based URIs and voice apps) and IM > (username-based URIs and various apps) have very different use cases and > requirements. Continuing to try to jam them together is > counter-productive. Separating them will accelerate each track of work. > > * This recognizes that it is not for us to decide if TN or name-based > URIs win/lose in the end. We work to accomodate applications that use > both; the market and implementers will ultimately decide upon success or > failure. > > * Many of the pieces of the infrastructure used converge in the > architecture document, though there will be important differences in > some cases. There is enough similarity and potential for shared > elements that one overall architecture seems to hold some promise. > > * Out of that flows application / implementation-specific docs, on > message flows, DNS/NAPTR, etc. These should very specifically tell an > implementer what they need to do. > > * There are 3 likely stages or levels of deployment that should be > accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open Internet). > Depending upon the implementer, the maturity of their > app/business/users/regulations/etc., one may make sense. In general, > the lifecycle is Direct --> Federated --> Open. It is impossible for us > to predict or guide when the market or implementers will go to each > stage; we should try to describe how to do each and let implementers > figure out the rest. This also recognizes that this is not a battle of > direct vs. federated vs. open, as each has a place and a role. > > --> CURRENT Goals and Milestones: > Jul 2006 Submit SPEERMINT terminology I-D (Informational) > > Sep 2006 Submit I-D defining the SPEERMINT routing > architecture (Informational) > Dec 2006 Submit I-D defining the message flows associated > with the SPEERMINT routing architecture (Informational) > Jan 2007 Submit I-D on the use of DNS SRV and NAPTR > records as specified by RFC 3263 (BCP) > Mar 2007 Submit I-D on the minimum set of requirements > for SIP-based VoIP interconnection (BCP) > Jul 2007 Submit I-D specifying the use of strong > identities in session peering and supporting the establishment and > exchange of trust between domains (BCP) > Jul 2007 Submit I-D(s) on use cases (BCP) > Jul 2007 Propose re-chartering for any additional > efforts/considerations, or propose conclusion of working group > (following approval of last documents) > > --> PROPOSED New Goals and Milestones: > Apr 2007 Submit SPEERMINT terminology I-D (Informational) > Aug 2007 Submit SPEERMINT VoIP-specific use cases I-D > (Informational) > Aug 2007 Submit SPEERMINT IM-specific use cases I-D > (Informational) > Jan 2008 Submit SPEERMINT architecture I-D (Informational) > Feb 2008 Submit SPEERMINT message flows I-D (Informational) > Feb 2008 Submit SPEERMINT DNS SRV and NAPTR use I-D (BCP) > Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP > interconnection. (BCP) > Mar 2008 Propose re-chartering for any additional > efforts/considerations, or propose conclusion of working group > (following approval of last documents) > > Regards > Jason > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 08:07:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ8E3-00013a-JF; Mon, 19 Feb 2007 08:06:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ8E2-0000zT-R7 for speermint@ietf.org; Mon, 19 Feb 2007 08:06:38 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJ8E1-0007Ts-86 for speermint@ietf.org; Mon, 19 Feb 2007 08:06:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Feb 2007 14:05:59 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646BF2@oefeg-s04.oefeg.loc> In-Reply-To: <E1HIA1q-0000dA-Ic@stiedprstage1.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt Thread-Index: AcdSDjfYDdqKb/DrRreh88hNwQzA/wCFTAbA From: "Stastny Richard" <Richard.Stastny@oefeg.at> To: <speermint@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Many thanks to the authors for this draft, claryfing the position of enterprise peering This fits very well to the recent discussions on the list if enterprise peering should be=20 treated differently or not. Some questions and comments: 1. I assume that Enterprise A may select the peering based on analysing the domain name of the SIP URI. Some domains may peer directly, some may peer via a carrier I. Is it also possible that an Enterprise A may peer with more than one carrier. And if yes, how does Enterprise A distinguish between the carriers 2. In section 5.1 you mention E.164-based URIs and non-E.164-based URI. I assume you mean here plain SIP URIs. The term non-E.164-bases URIs is ambiguous, because there are also non-E.164=20 phone numbers. 3. In 5.3 Routing you mention that Enterprises want to use domain names on their own (example.com) OTOH, if using E.164 numbers, you will also have to use the domain of the peering Carrier for incoming calls I think this issue requires further study, especially in the context of Infrastructure ENUM and also with Calling and=20 Connected Identities. Best regards Richard > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, February 16, 2007 9:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Use cases for Enterprise Peering using the Session > Initiation Protocol (SIP) > Author(s) : J. Elwell, B. Rodrig > Filename : draft-elwell-speermint-enterprise-usecases-00.txt > Pages : 15 > Date : 2007-2-16 >=20 > Work in the SPEERMINT Working Group has focused to some extent on > peering between carrier VoIP Service Providers (VSP). This draft > describes some use cases involving SIP peering between enterprise > VSPs, with and without the involvement of carrier VSPs, and also > peering between enterprise VSPs and carrier VSPs. It also discusses > some of the key technical considerations applicable to these use > cases. >=20 > This work is being discussed on the speermint@ietf.org mailing list. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us ecases-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-elwell-speermint-enterprise-usecases-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-elwell-speermint-enterprise-usecases- > 00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 09:28:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9US-00070X-3D; Mon, 19 Feb 2007 09:27:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9UQ-00070M-Q7 for speermint@ietf.org; Mon, 19 Feb 2007 09:27:38 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ9UN-0003Oq-7n for speermint@ietf.org; Mon, 19 Feb 2007 09:27:38 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JDP00I04S5EP9@siemenscomms.co.uk> for speermint@ietf.org; Mon, 19 Feb 2007 14:27:14 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <FF5YQDDL>; Mon, 19 Feb 2007 14:27:15 +0000 Content-return: allowed Date: Mon, 19 Feb 2007 14:27:14 +0000 From: "Elwell, John" <john.elwell@siemens.com> Subject: RE: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise- usecases-00.txt To: Stastny Richard <Richard.Stastny@oefeg.at>, speermint@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B1637F1@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Richard, Thanks for reading it and sending your comments. See below. John > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 19 February 2007 13:06 > To: speermint@ietf.org > Subject: [Speermint] RE: I-D > ACTION:draft-elwell-speermint-enterprise-usecases-00.txt > > Many thanks to the authors for this draft, > claryfing the position of enterprise peering > > This fits very well to the recent discussions > on the list if enterprise peering should be > treated differently or not. > > Some questions and comments: > > 1. I assume that Enterprise A may select the > peering based on analysing the domain name of > the SIP URI. Some domains may peer directly, some > may peer via a carrier I. [JRE] Yes > > Is it also possible that an Enterprise A may peer > with more than one carrier. And if yes, > how does Enterprise A distinguish between the carriers [JRE] This would have to be based on policy. So policy might say that for certain enterprises B, use carrier I, for certain other enterprises B used carrier J, for example. This could vary according to other factors, e.g., time of day. Where the starting point is an E.164 number, different prefixes could require different carriers according to policy, e.g., depending on country code. > > 2. In section 5.1 you mention E.164-based URIs > and non-E.164-based URI. I assume you mean here > plain SIP URIs. The term non-E.164-bases URIs > is ambiguous, because there are also non-E.164 > phone numbers. [JRE] Yes, SIP URIs. > > 3. In 5.3 Routing you mention that Enterprises > want to use domain names on their own (example.com) > > OTOH, if using E.164 numbers, you will also have > to use the domain of the peering Carrier for incoming calls > I think this issue requires further study, especially in the > context of Infrastructure ENUM and also with Calling and > Connected Identities. [JRE] It depends exactly what you mean by using E.164 numbers. I assume you mean something like the following: - the caller in enterprise A generates a request to tel:+123456789; - enterprise A determines that it needs to go to carrier.net; - carrier.net will somehow need to forward the request to enterprise B using either sip:+123456789@enterpriseB.com or tel:+123456789. It is no good sending a request to enterprise B using sip:+123456789@carrier.net, because that can't be interpreted by enterprise B. So please explain. Of course, the request from enterprise A to carrier might use sip:123456789@carrier.net. > > Best regards > Richard > > > > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, February 16, 2007 9:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D > ACTION:draft-elwell-speermint-enterprise-usecases-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Use cases for Enterprise Peering using the > Session > > Initiation Protocol (SIP) > > Author(s) : J. Elwell, B. Rodrig > > Filename : > draft-elwell-speermint-enterprise-usecases-00.txt > > Pages : 15 > > Date : 2007-2-16 > > > > Work in the SPEERMINT Working Group has focused to some extent on > > peering between carrier VoIP Service Providers (VSP). This draft > > describes some use cases involving SIP peering between enterprise > > VSPs, with and without the involvement of carrier VSPs, and also > > peering between enterprise VSPs and carrier VSPs. It also > discusses > > some of the key technical considerations applicable to these use > > cases. > > > > This work is being discussed on the speermint@ietf.org mailing > list. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-elwell-speermint-ent > erprise-us > ecases-00.txt > > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-elwell-speermint-enterprise-usecases-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-elwell-speermint-enterprise-usecases- > > 00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 09:28:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9US-00070h-AI; Mon, 19 Feb 2007 09:27:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9UQ-00070N-QO for speermint@ietf.org; Mon, 19 Feb 2007 09:27:38 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ9UP-0003QC-5Q for speermint@ietf.org; Mon, 19 Feb 2007 09:27:38 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2007 06:27:36 -0800 X-IronPort-AV: i="4.14,190,1170662400"; d="scan'208"; a="763372961:sNHT53751732" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1JERZPG015291; Mon, 19 Feb 2007 09:27:35 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1JERUOC003741; Mon, 19 Feb 2007 09:27:35 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 09:27:30 -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: [Speermint] RE: I-DACTION:draft-elwell-speermint-enterprise-usecases-00.txt Date: Mon, 19 Feb 2007 09:27:27 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3029D405E@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646BF2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-DACTION:draft-elwell-speermint-enterprise-usecases-00.txt Thread-Index: AcdSDjfYDdqKb/DrRreh88hNwQzA/wCFTAbAAANkDcA= References: <E1HIA1q-0000dA-Ic@stiedprstage1.ietf.org> <32755D354E6B65498C3BD9FD496C7D46646BF2@oefeg-s04.oefeg.loc> From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com> To: "Stastny Richard" <Richard.Stastny@oefeg.at>, <speermint@ietf.org> X-OriginalArrivalTime: 19 Feb 2007 14:27:30.0586 (UTC) FILETIME=[167EDFA0:01C75432] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5728; t=1171895256; x=1172759256; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20<mhammer@cisco.com> |Subject:=20RE=3A=20[Speermint]=20RE=3A=20I-DACTION=3Adraft-elwell-speerm int-enterprise-usecases-00.txt=20 |Sender:=20 |To:=20=22Stastny=20Richard=22=20<Richard.Stastny@oefeg.at>, =20<speermint @ietf.org>; bh=s/2p5d2INvbyVQP9IIjDDqzkT0XKTdr3Y4miMD+sP8M=; b=FSDh+0Pd0fjY/WJaSwGWj7HThWX64i/fpQQ+tqzUElPM0aBfThwlSmyoiw54DGVtgB56qmOk ahWiLdzLJ+l4Tll6T8+tvihE67CVOV1B64KCaLQpn368h1D3sxSQ43rN; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Monday, February 19, 2007 8:06 AM > To: speermint@ietf.org > Subject: [Speermint] RE:=20 > I-DACTION:draft-elwell-speermint-enterprise-usecases-00.txt=20 >=20 > Many thanks to the authors for this draft, claryfing the=20 > position of enterprise peering >=20 > This fits very well to the recent discussions on the list if=20 > enterprise peering should be treated differently or not. >=20 > Some questions and comments: >=20 > 1. I assume that Enterprise A may select the peering based on=20 > analysing the domain name of the SIP URI. Some domains may=20 > peer directly, some may peer via a carrier I. >=20 > Is it also possible that an Enterprise A may peer with more=20 > than one carrier. And if yes, how does Enterprise A=20 > distinguish between the carriers The choice of which carrier to peer with could depend on the target of the communications and the possibility that the target has also identified that carrier as a peer. If no such relationship exists, then other criteria could be used to select an outgoing carrier. Conversely, an incoming communications could depend on the source having a relationship with a carrier that is also listed by Ent-A as having a peering relationship. =20 > 2. In section 5.1 you mention E.164-based URIs and=20 > non-E.164-based URI. I assume you mean here plain SIP URIs.=20 > The term non-E.164-bases URIs is ambiguous, because there are=20 > also non-E.164 phone numbers. You may be confusing dialing strings versus an expanded E.164 nubmer. If it is just a string, then likely there is no difference from an arbitrary string as user-part of a SIP address. If so, there is no need to distinguish from a SIP address since lookups and routing should be base on the host-part. > 3. In 5.3 Routing you mention that Enterprises want to use=20 > domain names on their own (example.com) >=20 > OTOH, if using E.164 numbers, you will also have to use the=20 > domain of the peering Carrier for incoming calls I think this=20 > issue requires further study, especially in the context of=20 > Infrastructure ENUM and also with Calling and Connected Identities. Are you saying that <E.164>@example.com is not permitted? =20 Why? You need to study that assertion first. Mike >=20 > Best regards > Richard >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, February 16, 2007 9:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D=20 > ACTION:draft-elwell-speermint-enterprise-usecases-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Use cases for Enterprise Peering using the > Session > > Initiation Protocol (SIP) > > Author(s) : J. Elwell, B. Rodrig > > Filename : > draft-elwell-speermint-enterprise-usecases-00.txt > > Pages : 15 > > Date : 2007-2-16 > >=20 > > Work in the SPEERMINT Working Group has focused to some extent on > > peering between carrier VoIP Service Providers (VSP). This draft > > describes some use cases involving SIP peering between enterprise > > VSPs, with and without the involvement of carrier VSPs, and also > > peering between enterprise VSPs and carrier VSPs. It also > discusses > > some of the key technical considerations applicable to these use > > cases. > >=20 > > This work is being discussed on the speermint@ietf.org mailing > list. > >=20 > >=20 > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-elwell-speermint-ent > erprise-us > ecases-00.txt >=20 > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-elwell-speermint-enterprise-usecases-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-elwell-speermint-enterprise-usecases- > > 00.txt". > >=20 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 09:57:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9wy-0005ij-Ow; Mon, 19 Feb 2007 09:57:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9ww-0005hU-9Z for speermint@ietf.org; Mon, 19 Feb 2007 09:57:06 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJ9uM-0006wW-0z for speermint@ietf.org; Mon, 19 Feb 2007 09:54:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt Date: Mon, 19 Feb 2007 15:53:52 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646BFB@oefeg-s04.oefeg.loc> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B1637F1@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt Thread-Index: AcdUMgKDwtgxH+xhTN69YiWcY9LRMwAAbE8g From: "Stastny Richard" <Richard.Stastny@oefeg.at> To: "Elwell, John" <john.elwell@siemens.com>, <speermint@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Hi John, > > > > Is it also possible that an Enterprise A may peer > > with more than one carrier. And if yes, > > how does Enterprise A distinguish between the carriers > [JRE] This would have to be based on policy. So policy might say that for > certain enterprises B, use carrier I, for certain other enterprises B used > carrier J, for example. This could vary according to other factors, e.g., > time of day. Where the starting point is an E.164 number, different > prefixes > could require different carriers according to policy, e.g., depending on > country code. OK. I just wonder if enterprise A is using E.164 numbers and ENUM, what type of ENUM they use.=20 > > 3. In 5.3 Routing you mention that Enterprises > > want to use domain names on their own (example.com) > > > > OTOH, if using E.164 numbers, you will also have > > to use the domain of the peering Carrier for incoming calls > > I think this issue requires further study, especially in the > > context of Infrastructure ENUM and also with Calling and > > Connected Identities. > [JRE] It depends exactly what you mean by using E.164 numbers. > I assume you mean something like the following: > - the caller in enterprise A generates a request to tel:+123456789; > - enterprise A determines that it needs to go to carrier.net; > - carrier.net will somehow need to forward the request to enterprise B > using > either sip:+123456789@enterpriseB.com or tel:+123456789. It is no good > sending a request to enterprise B using sip:+123456789@carrier.net, > because > that can't be interpreted by enterprise B. > So please explain. Of course, the request from enterprise A to carrier > might > use sip:123456789@carrier.net. >=20 OK If you start with an E.164 number in Enterprise A, you may not know that the E.164 number is finally going to an Enterprise B. So the first ENUM mapping will be to carrier.net. So the carrier needs to have an=20 indication somewhere that this E.164 number is not going to a residential subscriber UA, but to an enterpriseB.com Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 09:59:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9yi-0007iH-9T; Mon, 19 Feb 2007 09:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ9yg-0007cp-P8 for speermint@ietf.org; Mon, 19 Feb 2007 09:58:54 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJ9yf-0007yd-Cb for speermint@ietf.org; Mon, 19 Feb 2007 09:58:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: I-DACTION:draft-elwell-speermint-enterprise-usecases-00.txt Date: Mon, 19 Feb 2007 15:58:21 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646BFC@oefeg-s04.oefeg.loc> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3029D405E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-DACTION:draft-elwell-speermint-enterprise-usecases-00.txt Thread-Index: AcdSDjfYDdqKb/DrRreh88hNwQzA/wCFTAbAAANkDcAAATXyMA== From: "Stastny Richard" <Richard.Stastny@oefeg.at> To: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>, <speermint@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org > > 2. In section 5.1 you mention E.164-based URIs and > > non-E.164-based URI. I assume you mean here plain SIP URIs. > > The term non-E.164-bases URIs is ambiguous, because there are > > also non-E.164 phone numbers. >=20 > You may be confusing dialing strings versus an expanded E.164 nubmer. > If it is just a string, then likely there is no difference from an > arbitrary string as user-part of a SIP address. If so, there is no need > to distinguish from a SIP address since lookups and routing should be > base on the host-part. Not all dialling string expand to E.164 numbers, I just wanted to mention that there are also dialling string which expand to non-E.164 numbers such as 112, 911 and others >=20 >=20 > > 3. In 5.3 Routing you mention that Enterprises want to use > > domain names on their own (example.com) > > > > OTOH, if using E.164 numbers, you will also have to use the > > domain of the peering Carrier for incoming calls I think this > > issue requires further study, especially in the context of > > Infrastructure ENUM and also with Calling and Connected Identities. >=20 > Are you saying that <E.164>@example.com is not permitted? > Why? You need to study that assertion first. >=20 See my reply to John Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 11:27:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBME-0000wQ-K5; Mon, 19 Feb 2007 11:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJBMD-0000vM-UY for speermint@ietf.org; Mon, 19 Feb 2007 11:27:17 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJBMC-0000MF-J9 for speermint@ietf.org; Mon, 19 Feb 2007 11:27:17 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JDP001AGXP3AD@siemenscomms.co.uk> for speermint@ietf.org; Mon, 19 Feb 2007 16:27:03 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <FF5YQGV5>; Mon, 19 Feb 2007 16:27:03 +0000 Content-return: allowed Date: Mon, 19 Feb 2007 16:27:02 +0000 From: "Elwell, John" <john.elwell@siemens.com> Subject: RE: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise- usecases-00.txt To: Stastny Richard <Richard.Stastny@oefeg.at>, speermint@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B1639EC@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Richard, In-line. John > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 19 February 2007 14:54 > To: Elwell, John; speermint@ietf.org > Subject: RE: [Speermint] RE: I-D > ACTION:draft-elwell-speermint-enterprise-usecases-00.txt > > Hi John, > > > > > > > Is it also possible that an Enterprise A may peer > > > with more than one carrier. And if yes, > > > how does Enterprise A distinguish between the carriers > > [JRE] This would have to be based on policy. So policy > might say that > for > > certain enterprises B, use carrier I, for certain other > enterprises B > used > > carrier J, for example. This could vary according to other factors, > e.g., > > time of day. Where the starting point is an E.164 number, different > > prefixes > > could require different carriers according to policy, e.g., > depending > on > > country code. > > OK. > I just wonder if enterprise A is using E.164 numbers and > ENUM, what type > > of ENUM they use. [JRE] Possibly, but doesn't have to be ENUM. If it is ENUM, I guess it would be something similar to infrastructure ENUM. > > > > 3. In 5.3 Routing you mention that Enterprises > > > want to use domain names on their own (example.com) > > > > > > OTOH, if using E.164 numbers, you will also have > > > to use the domain of the peering Carrier for incoming calls > > > I think this issue requires further study, especially in the > > > context of Infrastructure ENUM and also with Calling and > > > Connected Identities. > > [JRE] It depends exactly what you mean by using E.164 numbers. > > I assume you mean something like the following: > > - the caller in enterprise A generates a request to tel:+123456789; > > - enterprise A determines that it needs to go to carrier.net; > > - carrier.net will somehow need to forward the request to > enterprise B > > using > > either sip:+123456789@enterpriseB.com or tel:+123456789. It > is no good > > sending a request to enterprise B using sip:+123456789@carrier.net, > > because > > that can't be interpreted by enterprise B. > > So please explain. Of course, the request from enterprise A > to carrier > > might > > use sip:123456789@carrier.net. > > > OK > If you start with an E.164 number in Enterprise A, you may not know > that the E.164 number is finally going to an Enterprise B. So > the first > ENUM mapping will be to carrier.net. So the carrier needs to have an > indication somewhere that this E.164 number is not going to a > residential > subscriber UA, but to an enterpriseB.com [JRE] The various DNS look-ups might take you to a server within carrier.net, but this doesn't mean that the SIP Request-URI gets overwritten with SIP:+123456789@carrier.net, because that is not really where you are trying to get to. Maybe the Route header field is used, if there really is a need to put that SIP:+123456789@carrier.net (as opposed to sip:+123456789@enterpriseB.com) in the request. > > Richard > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 19 12:18:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJC9X-0005lF-TO; Mon, 19 Feb 2007 12:18:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJC9W-0005k1-Lb for speermint@ietf.org; Mon, 19 Feb 2007 12:18:14 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJC9V-0002U3-8h for speermint@ietf.org; Mon, 19 Feb 2007 12:18:14 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 841154C748; Mon, 19 Feb 2007 18:18:12 +0100 (CET) Date: Mon, 19 Feb 2007 18:18:12 +0100 From: Otmar Lendl <lendl@nic.at> To: speermint@ietf.org Subject: Re: [Speermint] [wg-business] Updating Milestones Message-ID: <20070219171812.GB11302@nic.at> Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Jason, thanks for the update and the work two put into this. On 2007/02/16 22:02, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote: > > A few key points: > > * This recognizes that VoIP (TN-based URIs and voice apps) and IM > (username-based URIs and various apps) have very different use cases and > requirements. Continuing to try to jam them together is > counter-productive. Separating them will accelerate each track of work. Agreed. > * This recognizes that it is not for us to decide if TN or name-based > URIs win/lose in the end. We work to accommodate applications that use > both; the market and implementers will ultimately decide upon success or > failure. Agreed as well. > * Out of that flows application / implementation-specific docs, on > message flows, DNS/NAPTR, etc. These should very specifically tell an > implementer what they need to do. I'm a bit worried about the classification of all the work as "Informational" or "BCP". That kind of implies that all the building blocks for the speermint solution are already there and just need to be assembled to implement all those use cases in real life. In various areas, that's certainly true: There is no need to re-invent SIP, TLS, Identity:, ENUM. There are other aspects where I think some protocol work is needed. These include: * Multi-hop routing. IMHO The whole premise of speermint is the fact that people do not run open SIP servers and thus RFC3263 alone won't get servers to talk to each other. Just look at the Enterprise Peering use-cases in the new draft: Multi-hop peerings are featured prominently there. Right now, I don't see which existing protocols could be used to select the correct set of transit carriers which can act as the bridge between source and destination enterprise. * Routing based on numbers Right now, I see only ENUM and TRIP as IETF standards in that area. TRIP hasn't seen any deployment, and ENUM is a simple mapping, but not a routing protocol. We run into the same issue as before: classic ENUM + RFC3263 won't cut it in a world, where SIP servers don't work like email servers. I really hope that the IETF will engineer a solution to this issues and not concede this space to proprietary third party service providers. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 20 03:46:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQdb-0001UF-Mg; Tue, 20 Feb 2007 03:46:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQdb-0001U7-09 for speermint@ietf.org; Tue, 20 Feb 2007 03:46:15 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJQdX-0004na-KQ for speermint@ietf.org; Tue, 20 Feb 2007 03:46:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt Date: Tue, 20 Feb 2007 09:45:32 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646C06@oefeg-s04.oefeg.loc> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B1639EC@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise-usecases-00.txt Thread-Index: AcdUQroztiysTMZWTSGL+A/EyQCI4gAiFQcg From: "Stastny Richard" <Richard.Stastny@oefeg.at> To: "Elwell, John" <john.elwell@siemens.com>, <speermint@ietf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org John, > > If you start with an E.164 number in Enterprise A, you may not know > > that the E.164 number is finally going to an Enterprise B. So > > the first > > ENUM mapping will be to carrier.net. So the carrier needs to have an > > indication somewhere that this E.164 number is not going to a > > residential > > subscriber UA, but to an enterpriseB.com > [JRE] The various DNS look-ups might take you to a server within > carrier.net, but this doesn't mean that the SIP Request-URI gets > overwritten > with SIP:+123456789@carrier.net, because that is not really where you are > trying to get to. Maybe the Route header field is used, if there really is > a > need to put that SIP:+123456789@carrier.net (as opposed to > sip:+123456789@enterpriseB.com) in the request. I understood it the other way round: You start with SIP:+123456789@carrier.net and end up in carrier.net with a mapping to SIP:+123456789@enterpriseB.com Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 20 04:10:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJR0J-0005QE-Jt; Tue, 20 Feb 2007 04:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJR0I-0005Q8-Tr for speermint@ietf.org; Tue, 20 Feb 2007 04:09:42 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJR0F-0001ar-Jq for speermint@ietf.org; Tue, 20 Feb 2007 04:09:42 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JDR00G2983IZB@siemenscomms.co.uk> for speermint@ietf.org; Tue, 20 Feb 2007 09:09:18 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <FF5YQ31R>; Tue, 20 Feb 2007 09:09:18 +0000 Content-return: allowed Date: Tue, 20 Feb 2007 09:09:16 +0000 From: "Elwell, John" <john.elwell@siemens.com> Subject: RE: [Speermint] RE: I-D ACTION:draft-elwell-speermint-enterprise- usecases-00.txt To: Stastny Richard <Richard.Stastny@oefeg.at>, speermint@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B163CCE@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 20 February 2007 08:46 > To: Elwell, John; speermint@ietf.org > Subject: RE: [Speermint] RE: I-D > ACTION:draft-elwell-speermint-enterprise-usecases-00.txt > > John, > > > > If you start with an E.164 number in Enterprise A, you > may not know > > > that the E.164 number is finally going to an Enterprise B. So > > > the first > > > ENUM mapping will be to carrier.net. So the carrier needs > to have an > > > indication somewhere that this E.164 number is not going to a > > > residential > > > subscriber UA, but to an enterpriseB.com > > [JRE] The various DNS look-ups might take you to a server within > > carrier.net, but this doesn't mean that the SIP Request-URI gets > > overwritten > > with SIP:+123456789@carrier.net, because that is not really > where you > are > > trying to get to. Maybe the Route header field is used, if there > really is > > a > > need to put that SIP:+123456789@carrier.net (as opposed to > > sip:+123456789@enterpriseB.com) in the request. > > I understood it the other way round: > You start with SIP:+123456789@carrier.net and end > up in carrier.net with a mapping to SIP:+123456789@enterpriseB.com > > Richard OK, that would be a possibility. It certainly isn't clear to me how this would work. It all comes down to how enterprise A gets its DNS entries for ENUM populated. John _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 20 16:30:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcY4-0003AM-Fq; Tue, 20 Feb 2007 16:29:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcY3-0003A9-8t for speermint@ietf.org; Tue, 20 Feb 2007 16:29:19 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcXy-0001gI-26 for speermint@ietf.org; Tue, 20 Feb 2007 16:29:19 -0500 Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.30396998; Tue, 20 Feb 2007 16:28:49 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 16:28:49 -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: [Speermint] [wg-business] Updating Milestones Date: Tue, 20 Feb 2007 16:28:48 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602B3BF2E@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] Updating Milestones Thread-Index: AcdUShk4HviH2/8FTomwyTZ/JQREqwAzDKIg References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> <20070219171812.GB11302@nic.at> From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> To: "Otmar Lendl" <lendl@nic.at>, <speermint@ietf.org> X-OriginalArrivalTime: 20 Feb 2007 21:28:49.0271 (UTC) FILETIME=[1C2DD870:01C75536] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org > * Out of that flows application / implementation-specific docs, on=20 > > message flows, DNS/NAPTR, etc. These should very=20 > specifically tell an=20 > > implementer what they need to do. >=20 > I'm a bit worried about the classification of all the work as=20 > "Informational" or "BCP". >=20 > That kind of implies that all the building blocks for the=20 > speermint solution are already there and just need to be=20 > assembled to implement all those use cases in real life. <snip> > I really hope that the IETF will engineer a solution to this=20 > issues and not concede this space to proprietary third party=20 > service providers. First off, the major point we wanted to convey was more that the main documents that flow from the work will help implementers in a concrete way. We can decide with the ADs how various documents are classified once they start to mature. =20 Also, I do not necessarily preclude any new protocol work, though our ADs have counseled to be careful in this as that work may rightly fall into other WGs. In the end, I would say let's cross that bridge when we come to it, so to speak. =20 If you have some suggestions on how multi-hop routing and routing based on numbers should occur that is not fully addressed elsewhere, I encourage you to start up some threads on the mailing list here. I suspect other folks may be experiencing the same issues you cite, but the only way to tell is to start up discussion. (I may recommend a separate thread / email for each item so we can segment discussion topics.) Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 21 16:56:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzQr-0000qB-Ug; Wed, 21 Feb 2007 16:55:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJzQq-0000q0-AF for speermint@ietf.org; Wed, 21 Feb 2007 16:55:24 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJzQn-0001sL-Vc for speermint@ietf.org; Wed, 21 Feb 2007 16:55:24 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 30A454C786; Wed, 21 Feb 2007 22:55:19 +0100 (CET) Date: Wed, 21 Feb 2007 22:55:19 +0100 From: Otmar Lendl <lendl@nic.at> To: speermint@ietf.org Message-ID: <20070221215519.GA11690@nic.at> Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com> <20070219171812.GB11302@nic.at> <45AEC6EF95942140888406588E1A6602B3BF2E@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A6602B3BF2E@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Speermint] Selecting the right ingress point X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org On 2007/02/20 22:02, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote: > > Also, I do not necessarily preclude any new protocol work, though our > ADs have counseled to be careful in this as that work may rightly fall > into other WGs. In the end, I would say let's cross that bridge when we > come to it, so to speak. The signs are on the wall, or to be more precise, in the requirements draft. For example: o Variability of the Call Address Data: A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP or user. The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability or customization of the response(s) depending on various elements, such as the identity of the originating or terminating user or user domain. The current proposal (draft-ietf-speermint-srv-naptr-use-01) just rehashes RFC3263 which specifies an algorithm which is independent of the identity of the originating network. It's just a function of (destination domain, DNS records) and thus cannot take into account who is asking the DNS (unless you propose to play with fire (i.e. split DNS)). > If you have some suggestions on how multi-hop routing and routing based > on numbers should occur that is not fully addressed elsewhere, I > encourage you to start up some threads on the mailing list here. There is some discussion on domain based multihop routing in http://tools.ietf.org/html/draft-lendl-speermint-federations-03 . I'll elaborate on the need for this in a future mail. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 11:59:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKdk6-0008GO-W8; Fri, 23 Feb 2007 11:57:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKdk5-0008Eb-Ny for speermint@ietf.org; Fri, 23 Feb 2007 11:57:57 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKdk2-0001mM-7G for speermint@ietf.org; Fri, 23 Feb 2007 11:57:57 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 4275B4C7AF; Fri, 23 Feb 2007 17:57:49 +0100 (CET) Date: Fri, 23 Feb 2007 17:57:49 +0100 From: Otmar Lendl <lendl@nic.at> To: speermint@ietf.org Message-ID: <20070223165749.GA27574@nic.at> Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Speermint] Multihop routing X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org On 2007/02/20 22:02, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote: > > If you have some suggestions on how multi-hop routing and routing based > on numbers should occur that is not fully addressed elsewhere, I > encourage you to start up some threads on the mailing list here. I > suspect other folks may be experiencing the same issues you cite, but > the only way to tell is to start up discussion. The issue is rather simple: One of the basic premises of SIP is the famous end-to-end principle: The destination uses the DNS to publish the IP addresses of its ingress elements. On the sender side, the call may be handed to one outbound- proxy, which is independent of the destination of the call. Between that outbound proxy and the ingress proxy all routing is pure layer3: no further SIP device is involved. To achieve worldwide reachability, the ingress elements of the destination must accept calls from any source on the Internet. Almost all of the scenarios as documented by current drafts in the speermint WG deviate from this model, they assume: * A VSP wants to control with whom he peers * Peering is done over private networks * Non-public databases are used to route calls over such interconnection networks. * In order to complete calls to any valid destination TN/URI, VSPs have to rely on the PSTN (as fall-back) and transit service providers. --------------------- What does that mean for a typical call? The SIP architecture assumes something like this: /---\ /---\ ---------------- /---\ /---\ |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| \---/ \---/ ---------------- \---/ \---/ whereas the speermint requirements lead to diagrams like this: /---\ /---\ /-----\ /-----\ /---\ /---\ |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| \---/ \---/ \-----/ \-----/ \---/ \---/ (with transit VSPs involved at the SIP layer). Real life is way more complicated: There are a lot of VSPs which interconnect to each other over private links, peering fabrics, or even over the Internet. If we start to draw that as a graph with VSPs as nodes and peerings as edges, than we have a text-book example of a generic network. A call from one side of the network to the other needs to find a path through this graph. Each step is a SIP peering, which could involve any number of layer3 hops between the SIP proxies. The SIP mechanisms are fine _within_ each step: The microcosmos of a peering fabric looks like the Internet as envisioned by the SIP standard: full L3 connectivity between participants plus a shared DNS tree including an ENUM branch. What SIP can't do is routing between these mini-Internets. There are no mechnisms to choose the best of a multitude of possible paths through the network of VSPs. That wasn't part of the design, as this is a radical departure from the sacred end to end principle. There are just two possible choices: * Convince the VSPs to adopt the end to end priciple and open up their networks (and forget about termination fees as a side effect), or * Be prepared to design a routing protocol on the SIP layer. (Compromises here don't look feasible to me, something like http://en.wikipedia.org/wiki/Open_settlement_protocol might be used to decouple the trust relations from connectivity, but I doubt that would be enough.) ------------ Here is an analogy from a bit lower on the protocol stack: If you want to send an IP packet over a switched ethernet infrastructure, you just need one ARP request to map IP address to MAC address which is used to send the packet on its way. Both sides don't care how many L2 switches are involved, and what version of the spanning tree protocol they use to build their mac-based forwarding table. As long as the whole network is a single broadcast domain, this works fine. If you have just a few other LANs you might employ proxy ARP to bridge these together. This band-aid is clearly insufficient once the single L2 network is split up in multiple networks connected via L3 routers. ARP is still fine within each segment, but a L3 routing protocol is needed to maintain connectivity on the IP layer. Substitute as follows: IP layer -> SIP layer IP address -> SIP URI (or Telephone number) MAC address -> IP address spanning tree -> BGP broadcast domain-> IP layer connectivity ARP -> DNS lookup to map domain to IP address proxy-ARP -> announcing non-local destinations in a fabric's DNS and thus L3 routing -> SIP routing Just as it would be ridiculous to propose to use proxy-ARP to solve the worldwide IP routing problem, I'd be very sceptical that one can solve the VoIP routing problem with minor tweaks of the RFC3263 rules. ------------ All this doesn't mean we don't need to talk about how individual peering fabrics (these mini-Internets) work and what BCPs with regards to SIP we need to come up with for them. But all that will never ever be enough to replace the PSTN as THE global voice network with a SIP-based alternative. Comments? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 13:35:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfFf-0007ys-9X; Fri, 23 Feb 2007 13:34:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfFe-0007yV-CC for speermint@ietf.org; Fri, 23 Feb 2007 13:34:38 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKfFc-00066i-TC for speermint@ietf.org; Fri, 23 Feb 2007 13:34:38 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JDX00HH8I9LTM@usaga01-in.huawei.com> for speermint@ietf.org; Fri, 23 Feb 2007 10:34:34 -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 1.25 (built Mar 3 2004)) with ESMTPA id <0JDX007LNI9IGI@usaga01-in.huawei.com> for speermint@ietf.org; Fri, 23 Feb 2007 10:34:33 -0800 (PST) Date: Fri, 23 Feb 2007 12:34:17 -0600 From: Spencer Dawkins <spencer@mcsr-labs.org> Subject: Re: [Speermint] Multihop routing To: speermint@ietf.org Message-id: <029d01c75779$39d88920$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 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: <20070223165749.GA27574@nic.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Hi, Otmar, Nice summary. Thanks, Spencer > On 2007/02/20 22:02, "Livingood, Jason" > <Jason_Livingood@cable.comcast.com> wrote: >> >> If you have some suggestions on how multi-hop routing and routing based >> on numbers should occur that is not fully addressed elsewhere, I >> encourage you to start up some threads on the mailing list here. I >> suspect other folks may be experiencing the same issues you cite, but >> the only way to tell is to start up discussion. > > The issue is rather simple: > > One of the basic premises of SIP is the famous end-to-end principle: > > The destination uses the DNS to publish the IP addresses of > its ingress elements. > > On the sender side, the call may be handed to one outbound- > proxy, which is independent of the destination of the call. > > Between that outbound proxy and the ingress proxy all > routing is pure layer3: no further SIP device is involved. > > To achieve worldwide reachability, the ingress elements of the > destination must accept calls from any source on the Internet. > > Almost all of the scenarios as documented by current drafts > in the speermint WG deviate from this model, they assume: > > * A VSP wants to control with whom he peers > > * Peering is done over private networks > > * Non-public databases are used to route calls over such > interconnection networks. > > * In order to complete calls to any valid destination TN/URI, > VSPs have to rely on the PSTN (as fall-back) and transit > service providers. > > --------------------- > > What does that mean for a typical call? The SIP architecture > assumes something like this: > > > /---\ /---\ ---------------- /---\ /---\ > |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > \---/ \---/ ---------------- \---/ \---/ > > whereas the speermint requirements lead to diagrams like this: > > /---\ /---\ /-----\ /-----\ /---\ /---\ > |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > \---/ \---/ \-----/ \-----/ \---/ \---/ > > (with transit VSPs involved at the SIP layer). > > > Real life is way more complicated: There are a lot of VSPs which > interconnect to each other over private links, peering fabrics, or even > over the Internet. > > If we start to draw that as a graph with VSPs as nodes and peerings as > edges, than we have a text-book example of a generic network. A call > from one side of the network to the other needs to find a path through > this graph. Each step is a SIP peering, which could involve any number > of layer3 hops between the SIP proxies. > > The SIP mechanisms are fine _within_ each step: The microcosmos of > a peering fabric looks like the Internet as envisioned by the SIP > standard: full L3 connectivity between participants plus a shared DNS > tree including an ENUM branch. > > What SIP can't do is routing between these mini-Internets. There are no > mechnisms to choose the best of a multitude of possible paths through > the network of VSPs. > > That wasn't part of the design, as this is a radical departure from the > sacred end to end principle. > > There are just two possible choices: > > * Convince the VSPs to adopt the end to end priciple and open > up their networks (and forget about termination fees as a side > effect), or > > * Be prepared to design a routing protocol on the SIP layer. > > (Compromises here don't look feasible to me, something like > http://en.wikipedia.org/wiki/Open_settlement_protocol might > be used to decouple the trust relations from connectivity, but > I doubt that would be enough.) > > ------------ > > Here is an analogy from a bit lower on the protocol stack: > > If you want to send an IP packet over a switched ethernet > infrastructure, you just need one ARP request to map IP address to MAC > address which is used to send the packet on its way. Both sides don't > care how many L2 switches are involved, and what version of the spanning > tree protocol they use to build their mac-based forwarding table. > > As long as the whole network is a single broadcast domain, this works > fine. If you have just a few other LANs you might employ proxy ARP to > bridge these together. > > This band-aid is clearly insufficient once the single L2 network is > split up in multiple networks connected via L3 routers. ARP is still > fine within each segment, but a L3 routing protocol is needed to > maintain connectivity on the IP layer. > > Substitute as follows: > > IP layer -> SIP layer > IP address -> SIP URI (or Telephone number) > MAC address -> IP address > spanning tree -> BGP > broadcast domain-> IP layer connectivity > ARP -> DNS lookup to map domain to IP address > proxy-ARP -> announcing non-local destinations in a > fabric's DNS > > and thus > > L3 routing -> SIP routing > > Just as it would be ridiculous to propose to use proxy-ARP to solve the > worldwide IP routing problem, I'd be very sceptical that one can solve > the VoIP routing problem with minor tweaks of the RFC3263 rules. > > ------------ > > All this doesn't mean we don't need to talk about how individual > peering fabrics (these mini-Internets) work and what BCPs with > regards to SIP we need to come up with for them. > > But all that will never ever be enough to replace the PSTN > as THE global voice network with a SIP-based alternative. > > Comments? > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 14:20:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfy2-000231-Or; Fri, 23 Feb 2007 14:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfy1-00022n-8G for speermint@ietf.org; Fri, 23 Feb 2007 14:20:29 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKfxl-0006dL-W3 for speermint@ietf.org; Fri, 23 Feb 2007 14:20:29 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 23 Feb 2007 14:19:51 -0500 id 01588147.45DF3E57.00005D4C In-Reply-To: <20070223165749.GA27574@nic.at> References: <20070223165749.GA27574@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <477B9038-B6BA-4979-BFD4-61E8DE11EB65@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton <andy@hxr.us> Subject: Re: [Speermint] Multihop routing Date: Fri, 23 Feb 2007 14:19:55 -0500 To: Otmar Lendl <lendl@nic.at> X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org This sounds like RFC 3219. -andy On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: > On 2007/02/20 22:02, "Livingood, Jason" > <Jason_Livingood@cable.comcast.com> wrote: >> >> If you have some suggestions on how multi-hop routing and routing >> based >> on numbers should occur that is not fully addressed elsewhere, I >> encourage you to start up some threads on the mailing list here. I >> suspect other folks may be experiencing the same issues you cite, but >> the only way to tell is to start up discussion. > > The issue is rather simple: > > One of the basic premises of SIP is the famous end-to-end principle: > > The destination uses the DNS to publish the IP addresses of > its ingress elements. > > On the sender side, the call may be handed to one outbound- > proxy, which is independent of the destination of the call. > > Between that outbound proxy and the ingress proxy all > routing is pure layer3: no further SIP device is involved. > > To achieve worldwide reachability, the ingress elements of the > destination must accept calls from any source on the Internet. > > Almost all of the scenarios as documented by current drafts > in the speermint WG deviate from this model, they assume: > > * A VSP wants to control with whom he peers > > * Peering is done over private networks > > * Non-public databases are used to route calls over such > interconnection networks. > > * In order to complete calls to any valid destination TN/URI, > VSPs have to rely on the PSTN (as fall-back) and transit > service providers. > > --------------------- > > What does that mean for a typical call? The SIP architecture > assumes something like this: > > > /---\ /---\ ---------------- /---\ /---\ > |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > \---/ \---/ ---------------- \---/ \---/ > > whereas the speermint requirements lead to diagrams like this: > > /---\ /---\ /-----\ /-----\ /---\ /---\ > |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > \---/ \---/ \-----/ \-----/ \---/ \---/ > > (with transit VSPs involved at the SIP layer). > > > Real life is way more complicated: There are a lot of VSPs which > interconnect to each other over private links, peering fabrics, or > even > over the Internet. > > If we start to draw that as a graph with VSPs as nodes and peerings as > edges, than we have a text-book example of a generic network. A call > from one side of the network to the other needs to find a path through > this graph. Each step is a SIP peering, which could involve any number > of layer3 hops between the SIP proxies. > > The SIP mechanisms are fine _within_ each step: The microcosmos of > a peering fabric looks like the Internet as envisioned by the SIP > standard: full L3 connectivity between participants plus a shared DNS > tree including an ENUM branch. > > What SIP can't do is routing between these mini-Internets. There > are no > mechnisms to choose the best of a multitude of possible paths through > the network of VSPs. > > That wasn't part of the design, as this is a radical departure from > the > sacred end to end principle. > > There are just two possible choices: > > * Convince the VSPs to adopt the end to end priciple and open > up their networks (and forget about termination fees as a side > effect), or > > * Be prepared to design a routing protocol on the SIP layer. > > (Compromises here don't look feasible to me, something like > http://en.wikipedia.org/wiki/Open_settlement_protocol might > be used to decouple the trust relations from connectivity, but > I doubt that would be enough.) > > ------------ > > Here is an analogy from a bit lower on the protocol stack: > > If you want to send an IP packet over a switched ethernet > infrastructure, you just need one ARP request to map IP address to MAC > address which is used to send the packet on its way. Both sides don't > care how many L2 switches are involved, and what version of the > spanning > tree protocol they use to build their mac-based forwarding table. > > As long as the whole network is a single broadcast domain, this works > fine. If you have just a few other LANs you might employ proxy ARP to > bridge these together. > > This band-aid is clearly insufficient once the single L2 network is > split up in multiple networks connected via L3 routers. ARP is still > fine within each segment, but a L3 routing protocol is needed to > maintain connectivity on the IP layer. > > Substitute as follows: > > IP layer -> SIP layer > IP address -> SIP URI (or Telephone number) > MAC address -> IP address > spanning tree -> BGP > broadcast domain-> IP layer connectivity > ARP -> DNS lookup to map domain to IP address > proxy-ARP -> announcing non-local destinations in a > fabric's DNS > > and thus > > L3 routing -> SIP routing > > Just as it would be ridiculous to propose to use proxy-ARP to solve > the > worldwide IP routing problem, I'd be very sceptical that one can solve > the VoIP routing problem with minor tweaks of the RFC3263 rules. > > ------------ > > All this doesn't mean we don't need to talk about how individual > peering fabrics (these mini-Internets) work and what BCPs with > regards to SIP we need to come up with for them. > > But all that will never ever be enough to replace the PSTN > as THE global voice network with a SIP-based alternative. > > Comments? > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 15:31:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKh3v-0001aD-KP; Fri, 23 Feb 2007 15:30:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKh3u-0001XP-N0 for speermint@ietf.org; Fri, 23 Feb 2007 15:30:38 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKh3q-0003qx-2S for speermint@ietf.org; Fri, 23 Feb 2007 15:30:38 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 23 Feb 2007 12:30:33 -0800 X-IronPort-AV: i="4.14,212,1170662400"; d="scan'208"; a="661113823:sNHT39124188" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Multihop routing Date: Fri, 23 Feb 2007 15:30:31 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28077B170C@proton.jnpr.net> In-Reply-To: <477B9038-B6BA-4979-BFD4-61E8DE11EB65@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-index: AcdXf8fb0CHr0yMeQ3KD4uFxgIV7FgAB8YlQ From: "Reinaldo Penno" <rpenno@juniper.net> To: "Andrew Newton" <andy@hxr.us>, "Otmar Lendl" <lendl@nic.at> X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org Reading Otmar's federation draft I had the impression that many practical problems related to multi-hop SIP routing were addresed there. IMO a SIP layer routing protocol have a very low chance (zero?) of not only becoming a WG item but being implemented as well.=20 This begs the question on what is going on with the federation drafts? They are not WG items, but they are referred byt other WG docs explicitly. Everytbody talks about it but in San Diego it seemed we did not get enough raised hands to make it a WG item.... So? > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Friday, February 23, 2007 11:20 AM > To: Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Multihop routing >=20 > This sounds like RFC 3219. >=20 > -andy >=20 > On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: >=20 > > On 2007/02/20 22:02, "Livingood, Jason" =20 > > <Jason_Livingood@cable.comcast.com> wrote: > >> > >> If you have some suggestions on how multi-hop routing and routing=20 > >> based on numbers should occur that is not fully addressed=20 > elsewhere,=20 > >> I encourage you to start up some threads on the mailing=20 > list here. I=20 > >> suspect other folks may be experiencing the same issues=20 > you cite, but=20 > >> the only way to tell is to start up discussion. > > > > The issue is rather simple: > > > > One of the basic premises of SIP is the famous end-to-end principle: > > > > The destination uses the DNS to publish the IP addresses of > > its ingress elements. > > > > On the sender side, the call may be handed to one outbound- > > proxy, which is independent of the destination of the call. > > > > Between that outbound proxy and the ingress proxy all > > routing is pure layer3: no further SIP device is involved. > > > > To achieve worldwide reachability, the ingress elements of the > > destination must accept calls from any source on the Internet. > > > > Almost all of the scenarios as documented by current drafts in the=20 > > speermint WG deviate from this model, they assume: > > > > * A VSP wants to control with whom he peers > > > > * Peering is done over private networks > > > > * Non-public databases are used to route calls over such > > interconnection networks. > > > > * In order to complete calls to any valid destination TN/URI, > > VSPs have to rely on the PSTN (as fall-back) and transit > > service providers. > > > > --------------------- > > > > What does that mean for a typical call? The SIP=20 > architecture assumes=20 > > something like this: > > > > > > /---\ /---\ ---------------- /---\ /---\ > > |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > > \---/ \---/ ---------------- \---/ \---/ > > > > whereas the speermint requirements lead to diagrams like this: > > > > /---\ /---\ /-----\ /-----\ /---\ /---\ > > |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > > \---/ \---/ \-----/ \-----/ \---/ \---/ > > > > (with transit VSPs involved at the SIP layer). > > > > > > Real life is way more complicated: There are a lot of VSPs which=20 > > interconnect to each other over private links, peering fabrics, or=20 > > even over the Internet. > > > > If we start to draw that as a graph with VSPs as nodes and=20 > peerings as=20 > > edges, than we have a text-book example of a generic=20 > network. A call=20 > > from one side of the network to the other needs to find a=20 > path through=20 > > this graph. Each step is a SIP peering, which could involve=20 > any number=20 > > of layer3 hops between the SIP proxies. > > > > The SIP mechanisms are fine _within_ each step: The=20 > microcosmos of a=20 > > peering fabric looks like the Internet as envisioned by the SIP > > standard: full L3 connectivity between participants plus a=20 > shared DNS=20 > > tree including an ENUM branch. > > > > What SIP can't do is routing between these mini-Internets.=20 > There are=20 > > no mechnisms to choose the best of a multitude of possible paths=20 > > through the network of VSPs. > > > > That wasn't part of the design, as this is a radical departure from=20 > > the sacred end to end principle. > > > > There are just two possible choices: > > > > * Convince the VSPs to adopt the end to end priciple and open > > up their networks (and forget about termination fees as a side > > effect), or > > > > * Be prepared to design a routing protocol on the SIP layer. > > > > (Compromises here don't look feasible to me, something like=20 > > http://en.wikipedia.org/wiki/Open_settlement_protocol might=20 > be used to=20 > > decouple the trust relations from connectivity, but I doubt=20 > that would=20 > > be enough.) > > > > ------------ > > > > Here is an analogy from a bit lower on the protocol stack: > > > > If you want to send an IP packet over a switched ethernet=20 > > infrastructure, you just need one ARP request to map IP=20 > address to MAC=20 > > address which is used to send the packet on its way. Both=20 > sides don't=20 > > care how many L2 switches are involved, and what version of the=20 > > spanning tree protocol they use to build their mac-based forwarding=20 > > table. > > > > As long as the whole network is a single broadcast domain,=20 > this works=20 > > fine. If you have just a few other LANs you might employ=20 > proxy ARP to=20 > > bridge these together. > > > > This band-aid is clearly insufficient once the single L2 network is=20 > > split up in multiple networks connected via L3 routers. ARP=20 > is still=20 > > fine within each segment, but a L3 routing protocol is needed to=20 > > maintain connectivity on the IP layer. > > > > Substitute as follows: > > > > IP layer -> SIP layer > > IP address -> SIP URI (or Telephone number) > > MAC address -> IP address > > spanning tree -> BGP > > broadcast domain-> IP layer connectivity > > ARP -> DNS lookup to map domain to IP address > > proxy-ARP -> announcing non-local destinations in a > > fabric's DNS > > > > and thus > > > > L3 routing -> SIP routing > > > > Just as it would be ridiculous to propose to use proxy-ARP to solve=20 > > the worldwide IP routing problem, I'd be very sceptical=20 > that one can=20 > > solve the VoIP routing problem with minor tweaks of the=20 > RFC3263 rules. > > > > ------------ > > > > All this doesn't mean we don't need to talk about how individual=20 > > peering fabrics (these mini-Internets) work and what BCPs=20 > with regards=20 > > to SIP we need to come up with for them. > > > > But all that will never ever be enough to replace the PSTN as THE=20 > > global voice network with a SIP-based alternative. > > > > Comments? > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 15:40:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhCg-0004Qt-Or; Fri, 23 Feb 2007 15:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhCg-0004Qo-1W for speermint@ietf.org; Fri, 23 Feb 2007 15:39:42 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhCc-00052q-Ma for speermint@ietf.org; Fri, 23 Feb 2007 15:39:42 -0500 Received: from ([10.195.246.152]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.30499139; Fri, 23 Feb 2007 15:39:24 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:39:24 -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: [Speermint] Selecting the right ingress point Date: Fri, 23 Feb 2007 15:39:23 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Selecting the right ingress point Thread-Index: AcdWBn+2leCQgcIwQWCY+SaHRjyMdABg5sSA References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com><20070219171812.GB11302@nic.at><45AEC6EF95942140888406588E1A6602B3BF2E@PACDCEXCMB04.cable.comcast.com> <20070221215519.GA11690@nic.at> From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> To: "Otmar Lendl" <lendl@nic.at>, <speermint@ietf.org> X-OriginalArrivalTime: 23 Feb 2007 20:39:24.0176 (UTC) FILETIME=[B4158100:01C7578A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org So basically, you want the ENUM server to give a different URI to a querying party, depending upon who that party is? For example, you are network1. If network2 queries your ENUM server for a URI lookup, you want them to go to border-element-1. But if network3 queries you, you want them to go to border-element-2. Yes? Jason PS - Which section of http://tools.ietf.org/html/draft-lendl-speermint-federations-03 should we refer people to read as background? (4.4.3?) > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Wednesday, February 21, 2007 4:55 PM > To: speermint@ietf.org > Subject: [Speermint] Selecting the right ingress point >=20 > On 2007/02/20 22:02, "Livingood, Jason"=20 > <Jason_Livingood@cable.comcast.com> wrote: > >=20 > > Also, I do not necessarily preclude any new protocol work,=20 > though our=20 > > ADs have counseled to be careful in this as that work may=20 > rightly fall=20 > > into other WGs. In the end, I would say let's cross that=20 > bridge when=20 > > we come to it, so to speak. >=20 > The signs are on the wall, or to be more precise, in the=20 > requirements draft. For example: >=20 > o Variability of the Call Address Data: > A terminating VSP/ASP or user SHOULD be able to indicate its > domain ingress points (Signaling Path Border=20 > Element(s)) based on > the identity of the originating VSP/ASP or user. > The mechanisms recommended for the use and resolution=20 > of the call > addressing data SHOULD allow for variability or customization of > the response(s) depending on various elements, such as the > identity of the originating or terminating user or user domain. >=20 > The current proposal (draft-ietf-speermint-srv-naptr-use-01)=20 > just rehashes RFC3263 which specifies an algorithm which is=20 > independent of the identity of the originating network. It's=20 > just a function of (destination domain, DNS records) and thus=20 > cannot take into account who is asking the DNS (unless you=20 > propose to play with fire (i.e. split DNS)). >=20 > > If you have some suggestions on how multi-hop routing and routing=20 > > based on numbers should occur that is not fully addressed=20 > elsewhere, I=20 > > encourage you to start up some threads on the mailing list here. >=20 > There is some discussion on domain based multihop routing in > http://tools.ietf.org/html/draft-lendl-speermint-federations-03 . >=20 > I'll elaborate on the need for this in a future mail. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 15:44:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhH1-0005vN-QW; Fri, 23 Feb 2007 15:44:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhGz-0005vB-RM for speermint@ietf.org; Fri, 23 Feb 2007 15:44:09 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhGy-0005cN-DF for speermint@ietf.org; Fri, 23 Feb 2007 15:44:09 -0500 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.1091376; Fri, 23 Feb 2007 15:43:49 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:43:49 -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: [Speermint] Multihop routing Date: Fri, 23 Feb 2007 15:43:48 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602FF7AD7@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdXf8fb0CHr0yMeQ3KD4uFxgIV7FgAB8YlQAADen9A= References: <9BD5D7887235424FA97DFC223CAE3C28077B170C@proton.jnpr.net> From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com> To: "Reinaldo Penno" <rpenno@juniper.net>, "Andrew Newton" <andy@hxr.us>, "Otmar Lendl" <lendl@nic.at> X-OriginalArrivalTime: 23 Feb 2007 20:43:49.0029 (UTC) FILETIME=[51F2DD50:01C7578B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Errors-To: speermint-bounces@ietf.org The federation work in definitely getting put into our work here. That starts with federation use cases going into the consolidated use cases and will result in federation requirements, an architecture that supports federations, etc. =20 As to a SIP layer routing protocol, that is likely to be out of scope here. BUT, that is not to say that we cannot document what our needs are and then refer that work to one of the other RAI WGs for resolution...=20 Jason=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 > Sent: Friday, February 23, 2007 3:31 PM > To: Andrew Newton; Otmar Lendl > Cc: speermint@ietf.org > Subject: RE: [Speermint] Multihop routing >=20 > Reading Otmar's federation draft I had the impression that=20 > many practical problems related to multi-hop SIP routing were=20 > addresed there. >=20 > IMO a SIP layer routing protocol have a very low chance=20 > (zero?) of not only becoming a WG item but being implemented as well.=20 >=20 > This begs the question on what is going on with the federation drafts? > They are not WG items, but they are referred byt other WG=20 > docs explicitly. Everytbody talks about it but in San Diego=20 > it seemed we did not get enough raised hands to make it a WG item.... >=20 > So? >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, February 23, 2007 11:20 AM > > To: Otmar Lendl > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Multihop routing > >=20 > > This sounds like RFC 3219. > >=20 > > -andy > >=20 > > On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: > >=20 > > > On 2007/02/20 22:02, "Livingood, Jason" =20 > > > <Jason_Livingood@cable.comcast.com> wrote: > > >> > > >> If you have some suggestions on how multi-hop routing=20 > and routing=20 > > >> based on numbers should occur that is not fully addressed > > elsewhere, > > >> I encourage you to start up some threads on the mailing > > list here. I > > >> suspect other folks may be experiencing the same issues > > you cite, but > > >> the only way to tell is to start up discussion. > > > > > > The issue is rather simple: > > > > > > One of the basic premises of SIP is the famous end-to-end=20 > principle: > > > > > > The destination uses the DNS to publish the IP addresses of > > > its ingress elements. > > > > > > On the sender side, the call may be handed to one outbound- > > > proxy, which is independent of the destination of the call. > > > > > > Between that outbound proxy and the ingress proxy all > > > routing is pure layer3: no further SIP device is involved. > > > > > > To achieve worldwide reachability, the ingress elements of the > > > destination must accept calls from any source on the Internet. > > > > > > Almost all of the scenarios as documented by current=20 > drafts in the=20 > > > speermint WG deviate from this model, they assume: > > > > > > * A VSP wants to control with whom he peers > > > > > > * Peering is done over private networks > > > > > > * Non-public databases are used to route calls over such > > > interconnection networks. > > > > > > * In order to complete calls to any valid destination TN/URI, > > > VSPs have to rely on the PSTN (as fall-back) and transit > > > service providers. > > > > > > --------------------- > > > > > > What does that mean for a typical call? The SIP > > architecture assumes > > > something like this: > > > > > > > > > /---\ /---\ ---------------- /---\ /---\ > > > |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > > > \---/ \---/ ---------------- \---/ \---/ > > > > > > whereas the speermint requirements lead to diagrams like this: > > > > > > /---\ /---\ /-----\ /-----\ /---\ /---\ > > > |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > > > \---/ \---/ \-----/ \-----/ \---/ \---/ > > > > > > (with transit VSPs involved at the SIP layer). > > > > > > > > > Real life is way more complicated: There are a lot of VSPs which=20 > > > interconnect to each other over private links, peering=20 > fabrics, or=20 > > > even over the Internet. > > > > > > If we start to draw that as a graph with VSPs as nodes and > > peerings as > > > edges, than we have a text-book example of a generic > > network. A call > > > from one side of the network to the other needs to find a > > path through > > > this graph. Each step is a SIP peering, which could involve > > any number > > > of layer3 hops between the SIP proxies. > > > > > > The SIP mechanisms are fine _within_ each step: The > > microcosmos of a > > > peering fabric looks like the Internet as envisioned by the SIP > > > standard: full L3 connectivity between participants plus a > > shared DNS > > > tree including an ENUM branch. > > > > > > What SIP can't do is routing between these mini-Internets.=20 > > There are > > > no mechnisms to choose the best of a multitude of possible paths=20 > > > through the network of VSPs. > > > > > > That wasn't part of the design, as this is a radical=20 > departure from=20 > > > the sacred end to end principle. > > > > > > There are just two possible choices: > > > > > > * Convince the VSPs to adopt the end to end priciple and open > > > up their networks (and forget about termination fees as a side > > > effect), or > > > > > > * Be prepared to design a routing protocol on the SIP layer. > > > > > > (Compromises here don't look feasible to me, something like=20 > > > http://en.wikipedia.org/wiki/Open_settlement_protocol might > > be used to > > > decouple the trust relations from connectivity, but I doubt > > that would > > > be enough.) > > > > > > ------------ > > > > > > Here is an analogy from a bit lower on the protocol stack: > > > > > > If you want to send an IP packet over a switched ethernet=20 > > > infrastructure, you just need one ARP request to map IP > > address to MAC > > > address which is used to send the packet on its way. Both > > sides don't > > > care how many L2 switches are involved, and what version of the=20 > > > spanning tree protocol they use to build their mac-based=20 > forwarding=20 > > > table. > > > > > > As long as the whole network is a single broadcast domain, > > this works > > > fine. If you have just a few other LANs you might employ > > proxy ARP to > > > bridge these together. > > > > > > This band-aid is clearly insufficient once the single L2=20 > network is=20 > > > split up in multiple networks connected via L3 routers. ARP > > is still > > > fine within each segment, but a L3 routing protocol is needed to=20 > > > maintain connectivity on the IP layer. > > > > > > Substitute as follows: > > > > > > IP layer -> SIP layer > > > IP address -> SIP URI (or Telephone number) > > > MAC address -> IP address > > > spanning tree -> BGP > > > broadcast domain-> IP layer connectivity > > > ARP -> DNS lookup to map domain to IP address > > > proxy-ARP -> announcing non-local destinations in a > > > fabric's DNS > > > > > > and thus > > > > > > L3 routing -> SIP routing > > > > > > Just as it would be ridiculous to propose to use=20 > proxy-ARP to solve=20 > > > the worldwide IP routing problem, I'd be very sceptical > > that one can > > > solve the VoIP routing problem with minor tweaks of the > > RFC3263 rules. > > > > > > ------------ > > > > > > All this doesn't mean we don't need to talk about how individual=20 > > > peering fabrics (these mini-Internets) work and what BCPs > > with regards > > > to SIP we need to come up with for them. > > > > > > But all that will never ever be enough to replace the PSTN as THE=20 > > > global voice network with a SIP-based alternative. > > > > > > Comments? > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 15:46:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhJ9-0006Im-TD; Fri, 23 Feb 2007 15:46:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhJ8-0006IY-P0 for speermint@ietf.org; Fri, 23 Feb 2007 15:46:22 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhJ8-0005so-0k for speermint@ietf.org; Fri, 23 Feb 2007 15:46:22 -0500 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 93EDFE8FE2; Fri, 23 Feb 2007 15:45:51 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:45:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Multihop routing Date: Fri, 23 Feb 2007 15:45:50 -0500 Message-ID: <FA035B2C8D1DB4438C54F1542A0EEBBC0413F953@EVS2.ams.gblxint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdXf8fb0CHr0yMeQ3KD4uFxgIV7FgAB8YlQAAEDF3I= From: "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com> To: "Reinaldo Penno" <rpenno@juniper.net>, "Andrew Newton" <andy@hxr.us>, "Otmar Lendl" <lendl@nic.at> X-OriginalArrivalTime: 23 Feb 2007 20:45:51.0815 (UTC) FILETIME=[9B228570:01C7578B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d53b06eede2bb6b618e318c7466f38f Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2123217170==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============2123217170== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7578B.9A7E8222" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7578B.9A7E8222 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even with the federation draft, I believe that the problem still exists, = just moved slightly. Equate the SIP domain, either P2P or Federation = model, to an autonomous system, and the problem lies with there being no = SIP inter-AS mechanisms. -AU -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Fri Feb 23 15:32:58 2007 To: Andrew Newton; Otmar Lendl Cc: speermint@ietf.org Subject: RE: [Speermint] Multihop routing Reading Otmar's federation draft I had the impression that many practical problems related to multi-hop SIP routing were addresed there. IMO a SIP layer routing protocol have a very low chance (zero?) of not only becoming a WG item but being implemented as well.=20 This begs the question on what is going on with the federation drafts? They are not WG items, but they are referred byt other WG docs explicitly. Everytbody talks about it but in San Diego it seemed we did not get enough raised hands to make it a WG item.... So? > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Friday, February 23, 2007 11:20 AM > To: Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Multihop routing >=20 > This sounds like RFC 3219. >=20 > -andy >=20 > On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: >=20 > > On 2007/02/20 22:02, "Livingood, Jason" =20 > > <Jason_Livingood@cable.comcast.com> wrote: > >> > >> If you have some suggestions on how multi-hop routing and routing=20 > >> based on numbers should occur that is not fully addressed=20 > elsewhere,=20 > >> I encourage you to start up some threads on the mailing=20 > list here. I=20 > >> suspect other folks may be experiencing the same issues=20 > you cite, but=20 > >> the only way to tell is to start up discussion. > > > > The issue is rather simple: > > > > One of the basic premises of SIP is the famous end-to-end principle: > > > > The destination uses the DNS to publish the IP addresses of > > its ingress elements. > > > > On the sender side, the call may be handed to one outbound- > > proxy, which is independent of the destination of the call. > > > > Between that outbound proxy and the ingress proxy all > > routing is pure layer3: no further SIP device is involved. > > > > To achieve worldwide reachability, the ingress elements of the > > destination must accept calls from any source on the Internet. > > > > Almost all of the scenarios as documented by current drafts in the=20 > > speermint WG deviate from this model, they assume: > > > > * A VSP wants to control with whom he peers > > > > * Peering is done over private networks > > > > * Non-public databases are used to route calls over such > > interconnection networks. > > > > * In order to complete calls to any valid destination TN/URI, > > VSPs have to rely on the PSTN (as fall-back) and transit > > service providers. > > > > --------------------- > > > > What does that mean for a typical call? The SIP=20 > architecture assumes=20 > > something like this: > > > > > > /---\ /---\ ---------------- /---\ /---\ > > |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > > \---/ \---/ ---------------- \---/ \---/ > > > > whereas the speermint requirements lead to diagrams like this: > > > > /---\ /---\ /-----\ /-----\ /---\ /---\ > > |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > > \---/ \---/ \-----/ \-----/ \---/ \---/ > > > > (with transit VSPs involved at the SIP layer). > > > > > > Real life is way more complicated: There are a lot of VSPs which=20 > > interconnect to each other over private links, peering fabrics, or=20 > > even over the Internet. > > > > If we start to draw that as a graph with VSPs as nodes and=20 > peerings as=20 > > edges, than we have a text-book example of a generic=20 > network. A call=20 > > from one side of the network to the other needs to find a=20 > path through=20 > > this graph. Each step is a SIP peering, which could involve=20 > any number=20 > > of layer3 hops between the SIP proxies. > > > > The SIP mechanisms are fine _within_ each step: The=20 > microcosmos of a=20 > > peering fabric looks like the Internet as envisioned by the SIP > > standard: full L3 connectivity between participants plus a=20 > shared DNS=20 > > tree including an ENUM branch. > > > > What SIP can't do is routing between these mini-Internets.=20 > There are=20 > > no mechnisms to choose the best of a multitude of possible paths=20 > > through the network of VSPs. > > > > That wasn't part of the design, as this is a radical departure from=20 > > the sacred end to end principle. > > > > There are just two possible choices: > > > > * Convince the VSPs to adopt the end to end priciple and open > > up their networks (and forget about termination fees as a side > > effect), or > > > > * Be prepared to design a routing protocol on the SIP layer. > > > > (Compromises here don't look feasible to me, something like=20 > > http://en.wikipedia.org/wiki/Open_settlement_protocol might=20 > be used to=20 > > decouple the trust relations from connectivity, but I doubt=20 > that would=20 > > be enough.) > > > > ------------ > > > > Here is an analogy from a bit lower on the protocol stack: > > > > If you want to send an IP packet over a switched ethernet=20 > > infrastructure, you just need one ARP request to map IP=20 > address to MAC=20 > > address which is used to send the packet on its way. Both=20 > sides don't=20 > > care how many L2 switches are involved, and what version of the=20 > > spanning tree protocol they use to build their mac-based forwarding=20 > > table. > > > > As long as the whole network is a single broadcast domain,=20 > this works=20 > > fine. If you have just a few other LANs you might employ=20 > proxy ARP to=20 > > bridge these together. > > > > This band-aid is clearly insufficient once the single L2 network is=20 > > split up in multiple networks connected via L3 routers. ARP=20 > is still=20 > > fine within each segment, but a L3 routing protocol is needed to=20 > > maintain connectivity on the IP layer. > > > > Substitute as follows: > > > > IP layer -> SIP layer > > IP address -> SIP URI (or Telephone number) > > MAC address -> IP address > > spanning tree -> BGP > > broadcast domain-> IP layer connectivity > > ARP -> DNS lookup to map domain to IP address > > proxy-ARP -> announcing non-local destinations in a > > fabric's DNS > > > > and thus > > > > L3 routing -> SIP routing > > > > Just as it would be ridiculous to propose to use proxy-ARP to solve=20 > > the worldwide IP routing problem, I'd be very sceptical=20 > that one can=20 > > solve the VoIP routing problem with minor tweaks of the=20 > RFC3263 rules. > > > > ------------ > > > > All this doesn't mean we don't need to talk about how individual=20 > > peering fabrics (these mini-Internets) work and what BCPs=20 > with regards=20 > > to SIP we need to come up with for them. > > > > But all that will never ever be enough to replace the PSTN as THE=20 > > global voice network with a SIP-based alternative. > > > > Comments? > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C7578B.9A7E8222 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>RE: [Speermint] Multihop routing

Even with the federation draft, I believe that the = problem still exists, just moved slightly.  Equate the SIP domain, = either P2P or Federation model, to an autonomous system, and the problem = lies with there being no SIP inter-AS mechanisms.

-AU

 -----Original Message-----
From:   Reinaldo Penno [mailto:rpenno@juniper.net]
Sent:   Fri Feb 23 15:32:58 2007
To:     Andrew Newton; Otmar Lendl
Cc:     speermint@ietf.org
Subject:        RE: [Speermint] = Multihop routing

Reading Otmar's federation draft I had the impression that many
practical problems related to multi-hop SIP routing were addresed = there.

IMO a SIP layer routing protocol have a very low chance (zero?) of = not
only becoming a WG item but being implemented as well.

This begs the question on what is going on with the federation = drafts?
They are not WG items, but they are referred byt other WG docs
explicitly. Everytbody talks about it but in San Diego it seemed we = did
not get enough raised hands to make it a WG item....

So?

> -----Original Message-----
> From: Andrew Newton [mailto:andy@hxr.us]
> Sent: Friday, February 23, 2007 11:20 AM
> To: Otmar Lendl
> Cc: speermint@ietf.org
> Subject: Re: [Speermint] Multihop routing
>
> This sounds like RFC 3219.
>
> -andy
>
> On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote:
>
> > On 2007/02/20 22:02, "Livingood, Jason" 
> > <Jason_Livingood@cable.comcast.com> wrote:
> >>
> >> If you have some suggestions on how multi-hop routing and = routing
> >> based on numbers should occur that is not fully = addressed
> elsewhere,
> >> I encourage you to start up some threads on the = mailing
> list here.  I
> >> suspect other folks may be experiencing the same = issues
> you cite, but
> >> the only way to tell is to start up discussion.
> >
> > The issue is rather simple:
> >
> > One of the basic premises of SIP is the famous end-to-end = principle:
> >
> >   The destination uses the DNS to publish the IP = addresses of
> >   its ingress elements.
> >
> >   On the sender side, the call may be handed to one = outbound-
> >   proxy, which is independent of the destination of = the call.
> >
> >   Between that outbound proxy and the ingress proxy = all
> >   routing is pure layer3: no further SIP device is = involved.
> >
> >   To achieve worldwide reachability, the ingress = elements of the
> >   destination must accept calls from any source on = the Internet.
> >
> > Almost all of the scenarios as documented by current drafts in = the
> > speermint WG deviate from this model, they assume:
> >
> > * A VSP wants to control with whom he peers
> >
> > * Peering is done over private networks
> >
> > * Non-public databases are used to route calls over such
> >   interconnection networks.
> >
> > * In order to complete calls to any valid destination = TN/URI,
> >   VSPs have to rely on the PSTN (as fall-back) and = transit
> >   service providers.
> >
> > ---------------------
> >
> > What does that mean for a typical call? The SIP
> architecture assumes
> > something like this:
> >
> >
> >    /---\  /---\    = ----------------  /---\  /---\
> >    |UAC|--|VSP|-- / pure layer 3 / = --|VSP|--|UAC|
> >    \---/  \---/  = ----------------    \---/  \---/
> >
> > whereas the speermint requirements lead to diagrams like = this:
> >
> >    /---\  /---\  /-----\  = /-----\   /---\  /---\
> >    = |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC|
> >    \---/  \---/  \-----/  = \-----/   \---/  \---/
> >
> > (with transit VSPs involved at the SIP layer).
> >
> >
> > Real life is way more complicated: There are a lot of VSPs = which
> > interconnect to each other over private links, peering = fabrics, or
> > even over the Internet.
> >
> > If we start to draw that as a graph with VSPs as nodes and
> peerings as
> > edges, than we have a text-book example of a generic
> network. A call
> > from one side of the network to the other needs to find a
> path through
> > this graph. Each step is a SIP peering, which could = involve
> any number
> > of layer3 hops between the SIP proxies.
> >
> > The SIP mechanisms are fine _within_ each step: The
> microcosmos of a
> > peering fabric looks like the Internet as envisioned by the = SIP
> > standard: full L3 connectivity between participants plus a
> shared DNS
> > tree including an ENUM branch.
> >
> > What SIP can't do is routing between these mini-Internets.
> There are
> > no mechnisms to choose the best of a multitude of possible = paths
> > through the network of VSPs.
> >
> > That wasn't part of the design, as this is a radical departure = from
> > the sacred end to end principle.
> >
> > There are just two possible choices:
> >
> > * Convince the VSPs to adopt the end to end priciple and = open
> >   up their networks (and forget about termination = fees as a side
> >   effect), or
> >
> > * Be prepared to design a routing protocol on the SIP = layer.
> >
> > (Compromises here don't look feasible to me, something = like
> > http://en.= wikipedia.org/wiki/Open_settlement_protocol might
> be used to
> > decouple the trust relations from connectivity, but I = doubt
> that would
> > be enough.)
> >
> > ------------
> >
> > Here is an analogy from a bit lower on the protocol stack:
> >
> > If you want to send an IP packet over a switched ethernet
> > infrastructure, you just need one ARP request to map IP
> address to MAC
> > address which is used to send the packet on its way.  = Both
> sides don't
> > care how many L2 switches are involved, and what version of = the
> > spanning tree protocol they use to build their mac-based = forwarding
> > table.
> >
> > As long as the whole network is a single broadcast domain,
> this works
> > fine. If you have just a few other LANs you might employ
> proxy ARP to
> > bridge these together.
> >
> > This band-aid is clearly insufficient once the single L2 = network is
> > split up in multiple networks connected via L3 routers. = ARP
> is still
> > fine within each segment, but a L3 routing protocol is needed = to
> > maintain connectivity on the IP layer.
> >
> > Substitute as follows:
> >
> > IP layer    -> SIP layer
> > IP address  -> SIP URI  (or Telephone number)
> > MAC address -> IP address
> > spanning tree       -> = BGP
> > broadcast domain-> IP layer connectivity
> > ARP         -> DNS = lookup to map domain to IP address
> > proxy-ARP   -> announcing non-local destinations = in a
> >             =    fabric's DNS
> >
> > and thus
> >
> > L3 routing  -> SIP routing
> >
> > Just as it would be ridiculous to propose to use proxy-ARP to = solve
> > the worldwide IP routing problem, I'd be very sceptical
> that one can
> > solve the VoIP routing problem with minor tweaks of the
> RFC3263 rules.
> >
> > ------------
> >
> > All this doesn't mean we don't need to talk about how = individual
> > peering fabrics (these mini-Internets) work and what BCPs
> with regards
> > to SIP we need to come up with for them.
> >
> > But all that will never ever be enough to replace the PSTN as = THE
> > global voice network with a SIP-based alternative.
> >
> > Comments?
> >
> > /ol
> > --
> > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer = >
> >
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ie= tf.org/mailman/listinfo/speermint
>
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ie= tf.org/mailman/listinfo/speermint
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ie= tf.org/mailman/listinfo/speermint

------_=_NextPart_001_01C7578B.9A7E8222-- --===============2123217170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============2123217170==-- From speermint-bounces@ietf.org Fri Feb 23 15:50:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhMW-000504-5p; Fri, 23 Feb 2007 15:49:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhMU-0004wo-TO for speermint@ietf.org; Fri, 23 Feb 2007 15:49:50 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhMT-0006OX-FW for speermint@ietf.org; Fri, 23 Feb 2007 15:49:50 -0500 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l1NKnTBs018530; Fri, 23 Feb 2007 12:49:36 -0800 From: "Richard Shockey" To: "'Livingood, Jason'" , References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com><20070219171812.GB11302@nic.at><45AEC6EF95942140888406588E1A6602B3BF2E@PACDCEXCMB04.cable.comcast.com><20070221215519.GA11690@nic.at> <45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> Subject: RE: [Speermint] Selecting the right ingress point Date: Fri, 23 Feb 2007 15:49:19 -0500 Message-ID: <03bb01c7578c$18e88cc0$8d201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AcdWBn+2leCQgcIwQWCY+SaHRjyMdABg5sSAAABkXNA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@shockey.us List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, February 23, 2007 3:39 PM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Selecting the right ingress point > > So basically, you want the ENUM server to give a different URI to a > querying party, depending upon who that party is? > > For example, you are network1. If network2 queries your ENUM server for > a URI lookup, you want them to go to border-element-1. But if network3 > queries you, you want them to go to border-element-2. Right and just how would you validate whom the requestor is .. VPN's subnets... gee Otmar you've just made a fantastic argument for private ENUM. > > Yes? > > Jason > > PS - Which section of > http://tools.ietf.org/html/draft-lendl-speermint-federations-03 should > we refer people to read as background? (4.4.3?) > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Wednesday, February 21, 2007 4:55 PM > > To: speermint@ietf.org > > Subject: [Speermint] Selecting the right ingress point > > > > On 2007/02/20 22:02, "Livingood, Jason" > > wrote: > > > > > > Also, I do not necessarily preclude any new protocol work, > > though our > > > ADs have counseled to be careful in this as that work may > > rightly fall > > > into other WGs. In the end, I would say let's cross that > > bridge when > > > we come to it, so to speak. > > > > The signs are on the wall, or to be more precise, in the > > requirements draft. For example: > > > > o Variability of the Call Address Data: > > A terminating VSP/ASP or user SHOULD be able to indicate its > > domain ingress points (Signaling Path Border > > Element(s)) based on > > the identity of the originating VSP/ASP or user. > > The mechanisms recommended for the use and resolution > > of the call > > addressing data SHOULD allow for variability or customization of > > the response(s) depending on various elements, such as the > > identity of the originating or terminating user or user domain. > > > > The current proposal (draft-ietf-speermint-srv-naptr-use-01) > > just rehashes RFC3263 which specifies an algorithm which is > > independent of the identity of the originating network. It's > > just a function of (destination domain, DNS records) and thus > > cannot take into account who is asking the DNS (unless you > > propose to play with fire (i.e. split DNS)). > > > > > If you have some suggestions on how multi-hop routing and routing > > > based on numbers should occur that is not fully addressed > > elsewhere, I > > > encourage you to start up some threads on the mailing list here. > > > > There is some discussion on domain based multihop routing in > > http://tools.ietf.org/html/draft-lendl-speermint-federations-03 . > > > > I'll elaborate on the need for this in a future mail. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 16:04:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhaN-0007KI-Ow; Fri, 23 Feb 2007 16:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhaN-0007K3-0V for speermint@ietf.org; Fri, 23 Feb 2007 16:04:11 -0500 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhZy-0000mr-8k for speermint@ietf.org; Fri, 23 Feb 2007 16:04:10 -0500 Received: from ([24.40.15.92]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.5099449; Fri, 23 Feb 2007 16:03:22 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 16:03:22 -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: [Speermint] Multihop routing Date: Fri, 23 Feb 2007 16:03:21 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602FF7AD9@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdXbGvwn4w36gTQQbu4TUpQDYjliwAHvYDQ References: <20070223165749.GA27574@nic.at> From: "Livingood, Jason" To: "Otmar Lendl" , X-OriginalArrivalTime: 23 Feb 2007 21:03:22.0393 (UTC) FILETIME=[0D540090:01C7578E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > The issue is rather simple: > The SIP mechanisms are fine _within_ each step: The=20 > microcosmos of a peering fabric looks like the Internet as=20 > envisioned by the SIP > standard: full L3 connectivity between participants plus a=20 > shared DNS tree including an ENUM branch. >=20 > What SIP can't do is routing between these mini-Internets.=20 > There are no mechnisms to choose the best of a multitude of=20 > possible paths through the network of VSPs. I think now you are getting to the heart of your concerns... > There are just two possible choices: >=20 > * Convince the VSPs to adopt the end to end priciple and open > up their networks (and forget about termination fees as a side > effect), or Our collective chances of achieving this by force of standards is zero. But we are laying out a path to go from direct -> federated -> open. =20 The market will choose its own pace. > * Be prepared to design a routing protocol on the SIP layer. >=20 > (Compromises here don't look feasible to me, something like=20 > http://en.wikipedia.org/wiki/Open_settlement_protocol might=20 > be used to decouple the trust relations from connectivity,=20 > but I doubt that would be enough.) I think it is time to call in some gurus from SIP WGs to start to comment... =20 JL _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 17:02:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKiU9-0003kf-CX; Fri, 23 Feb 2007 17:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKiU7-0003kY-Tg for speermint@ietf.org; Fri, 23 Feb 2007 17:01:47 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKiU6-0004hp-BL for speermint@ietf.org; Fri, 23 Feb 2007 17:01:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] Selecting the right ingress point Date: Fri, 23 Feb 2007 22:59:02 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C80@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Selecting the right ingress point Thread-Index: AcdWBn+2leCQgcIwQWCY+SaHRjyMdABg5sSAAABkXNAAAooHpQ== References: <45AEC6EF95942140888406588E1A6602B3BEDB@PACDCEXCMB04.cable.comcast.com><20070219171812.GB11302@nic.at><45AEC6EF95942140888406588E1A6602B3BF2E@PACDCEXCMB04.cable.comcast.com><20070221215519.GA11690@nic.at><45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> <03bb01c7578c$18e88cc0$8d201f0a@cis.neustar.com> From: "Stastny Richard" To: , "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >gee Otmar you've just made a fantastic argument for private ENUM =20 ? =20 I set up a private ENUM server for any VSP I peer with? Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Fr 23.02.2007 21:49 An: 'Livingood, Jason'; speermint@ietf.org Betreff: RE: [Speermint] Selecting the right ingress point > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Friday, February 23, 2007 3:39 PM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Selecting the right ingress point > > So basically, you want the ENUM server to give a different URI to a > querying party, depending upon who that party is? > > For example, you are network1. If network2 queries your ENUM server = for > a URI lookup, you want them to go to border-element-1. But if = network3 > queries you, you want them to go to border-element-2. Right and just how would you validate whom the requestor is .. VPN's subnets... gee Otmar you've just made a fantastic argument for private ENUM. > > Yes? > > Jason > > PS - Which section of > http://tools.ietf.org/html/draft-lendl-speermint-federations-03 should > we refer people to read as background? (4.4.3?) > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Wednesday, February 21, 2007 4:55 PM > > To: speermint@ietf.org > > Subject: [Speermint] Selecting the right ingress point > > > > On 2007/02/20 22:02, "Livingood, Jason" > > wrote: > > > > > > Also, I do not necessarily preclude any new protocol work, > > though our > > > ADs have counseled to be careful in this as that work may > > rightly fall > > > into other WGs. In the end, I would say let's cross that > > bridge when > > > we come to it, so to speak. > > > > The signs are on the wall, or to be more precise, in the > > requirements draft. For example: > > > > o Variability of the Call Address Data: > > A terminating VSP/ASP or user SHOULD be able to indicate its > > domain ingress points (Signaling Path Border > > Element(s)) based on > > the identity of the originating VSP/ASP or user. > > The mechanisms recommended for the use and resolution > > of the call > > addressing data SHOULD allow for variability or customization = of > > the response(s) depending on various elements, such as the > > identity of the originating or terminating user or user = domain. > > > > The current proposal (draft-ietf-speermint-srv-naptr-use-01) > > just rehashes RFC3263 which specifies an algorithm which is > > independent of the identity of the originating network. It's > > just a function of (destination domain, DNS records) and thus > > cannot take into account who is asking the DNS (unless you > > propose to play with fire (i.e. split DNS)). > > > > > If you have some suggestions on how multi-hop routing and routing > > > based on numbers should occur that is not fully addressed > > elsewhere, I > > > encourage you to start up some threads on the mailing list here. > > > > There is some discussion on domain based multihop routing in > > http://tools.ietf.org/html/draft-lendl-speermint-federations-03 . > > > > I'll elaborate on the need for this in a future mail. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 17:43:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKj7l-0006vu-9h; Fri, 23 Feb 2007 17:42:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKj7j-0006vY-Tt for speermint@ietf.org; Fri, 23 Feb 2007 17:42:43 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKj7f-0002tb-BN for speermint@ietf.org; Fri, 23 Feb 2007 17:42:43 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6F0B64C7B3; Fri, 23 Feb 2007 23:42:36 +0100 (CET) Date: Fri, 23 Feb 2007 23:42:36 +0100 From: Otmar Lendl To: "Livingood, Jason" Subject: Re: [Speermint] Selecting the right ingress point Message-ID: <20070223224236.GA6449@nic.at> Mail-Followup-To: Otmar Lendl , "Livingood, Jason" , speermint@ietf.org References: <20070221215519.GA11690@nic.at> <45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/23 21:02, "Livingood, Jason" wrote: > So basically, you want the ENUM server to give a different URI to a > querying party, depending upon who that party is? > I was talking about pure SIP, no ENUM involved. > For example, you are network1. If network2 queries your ENUM server for > a URI lookup, you want them to go to border-element-1. But if network3 > queries you, you want them to go to border-element-2. Generally speaking you can make any of the mapping steps from telephone number to IP address sensitive to the querying network: 1) Give different answers to ENUM queries 2) Give different answers to RFC 3263 NAPTR queries 3) Give different answers to SRV queries 4) Give different answers to A queries 5) Slightly modify 3263 to ask different questions depending on who's asking and/or which federation is used 6) Junk RFC 3263 and use other means to map SIP URI to an ingress point. 7) Use something other than plain ENUM to do the number->URI mapping > Yes? What my code implements is option 5). e.g. with my OpenSer Domainpolicy code a federation can modify the RFC3263 rules to prefix the domain with e.g. the federation name before doing the NAPTR/SRV lookup. Other options are to query a private DNS tree for these records. As I built my scheme in a way to work both for number-based dialing *and* URI based dialing, it didn't make sense to fiddle with the ENUM lookup as that cannot help me with URI-based calls. > PS - Which section of > http://tools.ietf.org/html/draft-lendl-speermint-federations-03 should > we refer people to read as background? (4.4.3?) My draft isn't very specific on what federations could use to get this source-dependent ingress points. A bit is in the examples: o Peering fabric based on SIP: A SIP hub acts as a forwarding proxy between participants. Intra-federation calls are to be routed through the SIP hub. in that case, no NAPTR/SRV/A lookups are performed for intra-federation calls: all VSPs just route to the central SIP hub. You can find more specifics in the documentation to my code, see http://openser.org/docs/modules/1.2.x/domainpolicy.html. Klaus' HOWTO is contains more examples, but it refers to a slightly older versions of the code. You can read it here: http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downloaddata=46 My slides from the Philly interim meeting contain examples as well, see http://www.enum.at/ietf/20060918-speermint-interim.ppt (Slides 28ff) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 21:10:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKmM7-0002X6-6i; Fri, 23 Feb 2007 21:09:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKmM5-0002Wz-FN for speermint@ietf.org; Fri, 23 Feb 2007 21:09:45 -0500 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKmLz-0002cx-CC for speermint@ietf.org; Fri, 23 Feb 2007 21:09:45 -0500 Received: from 85-125-242-85.teleworker.xdsl-line.inode.at ([85.125.242.85] helo=[192.168.1.101]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HKmLi-0008G8-Gj; Sat, 24 Feb 2007 03:09:23 +0100 In-Reply-To: <477B9038-B6BA-4979-BFD4-61E8DE11EB65@hxr.us> References: <20070223165749.GA27574@nic.at> <477B9038-B6BA-4979-BFD4-61E8DE11EB65@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21FCD2BA-89B0-406B-BFA1-923A235C3187@inode.at> Content-Transfer-Encoding: 7bit From: Michael Haberler Date: Sat, 24 Feb 2007 03:09:15 +0100 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 85.125.242.85 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7-deb Subject: Re: [Speermint] Multihop routing X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Am 23.02.2007 um 20:19 schrieb Andrew Newton: > This sounds like RFC 3219. yes - modulo protocol economics. if telephone numbers or prefixes are deemed a good choice as the primary routing key and full transitivity of the routing matrix is a requirement, then indeed TRIP would be a solution. our assumptions behind the Lendl federation/discovery I-D's were: a) numbers/prefixes are needed for endpoint and/or ingress resolution BUT they are bad choice for a routing key long term. "Private ENUM club equals federation" is a short term fix for those buying into the long-term downside. b) long term the average transit path length will go down, approaching end-to-end asymptotically. c) full transitivity is not a requirement since the voice transit business models don't scale to arbitrary path length in the first place, likely less so as time progresses - note this is different from the total connectivity promise delivered by BGP (get everywhere cheapest according to some cost criteria) which is why we assumed an incremental, on demand target discovery model gets you most of the TRIP benefits at a fraction of the cost and without number legacies. Improve it by cache priming for a near- optimum routing and you cover lots of scenarios - like enterprise to enterprise. that's why I think the TRIP economics doesnt fly: important problem, total solution, wrong primary key to solution, adoption cost not justifiable WRT benefits. -Michael > > -andy > > On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: > >> On 2007/02/20 22:02, "Livingood, Jason" >> wrote: >>> >>> If you have some suggestions on how multi-hop routing and routing >>> based >>> on numbers should occur that is not fully addressed elsewhere, I >>> encourage you to start up some threads on the mailing list here. I >>> suspect other folks may be experiencing the same issues you cite, >>> but >>> the only way to tell is to start up discussion. >> >> The issue is rather simple: >> >> One of the basic premises of SIP is the famous end-to-end principle: >> >> The destination uses the DNS to publish the IP addresses of >> its ingress elements. >> >> On the sender side, the call may be handed to one outbound- >> proxy, which is independent of the destination of the call. >> >> Between that outbound proxy and the ingress proxy all >> routing is pure layer3: no further SIP device is involved. >> >> To achieve worldwide reachability, the ingress elements of the >> destination must accept calls from any source on the Internet. >> >> Almost all of the scenarios as documented by current drafts >> in the speermint WG deviate from this model, they assume: >> >> * A VSP wants to control with whom he peers >> >> * Peering is done over private networks >> >> * Non-public databases are used to route calls over such >> interconnection networks. >> >> * In order to complete calls to any valid destination TN/URI, >> VSPs have to rely on the PSTN (as fall-back) and transit >> service providers. >> >> --------------------- >> >> What does that mean for a typical call? The SIP architecture >> assumes something like this: >> >> >> /---\ /---\ ---------------- /---\ /---\ >> |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| >> \---/ \---/ ---------------- \---/ \---/ >> >> whereas the speermint requirements lead to diagrams like this: >> >> /---\ /---\ /-----\ /-----\ /---\ /---\ >> |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| >> \---/ \---/ \-----/ \-----/ \---/ \---/ >> >> (with transit VSPs involved at the SIP layer). >> >> >> Real life is way more complicated: There are a lot of VSPs which >> interconnect to each other over private links, peering fabrics, or >> even >> over the Internet. >> >> If we start to draw that as a graph with VSPs as nodes and >> peerings as >> edges, than we have a text-book example of a generic network. A call >> from one side of the network to the other needs to find a path >> through >> this graph. Each step is a SIP peering, which could involve any >> number >> of layer3 hops between the SIP proxies. >> >> The SIP mechanisms are fine _within_ each step: The microcosmos of >> a peering fabric looks like the Internet as envisioned by the SIP >> standard: full L3 connectivity between participants plus a shared DNS >> tree including an ENUM branch. >> >> What SIP can't do is routing between these mini-Internets. There >> are no >> mechnisms to choose the best of a multitude of possible paths through >> the network of VSPs. >> >> That wasn't part of the design, as this is a radical departure >> from the >> sacred end to end principle. >> >> There are just two possible choices: >> >> * Convince the VSPs to adopt the end to end priciple and open >> up their networks (and forget about termination fees as a side >> effect), or >> >> * Be prepared to design a routing protocol on the SIP layer. >> >> (Compromises here don't look feasible to me, something like >> http://en.wikipedia.org/wiki/Open_settlement_protocol might >> be used to decouple the trust relations from connectivity, but >> I doubt that would be enough.) >> >> ------------ >> >> Here is an analogy from a bit lower on the protocol stack: >> >> If you want to send an IP packet over a switched ethernet >> infrastructure, you just need one ARP request to map IP address to >> MAC >> address which is used to send the packet on its way. Both sides >> don't >> care how many L2 switches are involved, and what version of the >> spanning >> tree protocol they use to build their mac-based forwarding table. >> >> As long as the whole network is a single broadcast domain, this works >> fine. If you have just a few other LANs you might employ proxy ARP to >> bridge these together. >> >> This band-aid is clearly insufficient once the single L2 network is >> split up in multiple networks connected via L3 routers. ARP is still >> fine within each segment, but a L3 routing protocol is needed to >> maintain connectivity on the IP layer. >> >> Substitute as follows: >> >> IP layer -> SIP layer >> IP address -> SIP URI (or Telephone number) >> MAC address -> IP address >> spanning tree -> BGP >> broadcast domain-> IP layer connectivity >> ARP -> DNS lookup to map domain to IP address >> proxy-ARP -> announcing non-local destinations in a >> fabric's DNS >> >> and thus >> >> L3 routing -> SIP routing >> >> Just as it would be ridiculous to propose to use proxy-ARP to >> solve the >> worldwide IP routing problem, I'd be very sceptical that one can >> solve >> the VoIP routing problem with minor tweaks of the RFC3263 rules. >> >> ------------ >> >> All this doesn't mean we don't need to talk about how individual >> peering fabrics (these mini-Internets) work and what BCPs with >> regards to SIP we need to come up with for them. >> >> But all that will never ever be enough to replace the PSTN >> as THE global voice network with a SIP-based alternative. >> >> Comments? >> >> /ol >> -- >> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Feb 23 22:51:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKnvS-0003N3-Ve; Fri, 23 Feb 2007 22:50:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKnvR-0003JG-5Q for speermint@ietf.org; Fri, 23 Feb 2007 22:50:21 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKnvM-0000az-Sn for speermint@ietf.org; Fri, 23 Feb 2007 22:50:21 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 23 Feb 2007 19:50:16 -0800 X-IronPort-AV: i="4.14,213,1170662400"; d="scan'208"; a="661260085:sNHT215640988" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Feb 2007 22:50:14 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28077B1804@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [enum-wg] Thesis on Infrastructure ENUM options for the Netherlands Thread-index: AcdU0RRiVPkI2g/+R1yWVIesYwtBhAABVbwAALwGspA= From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Speermint] FW: [enum-wg] Thesis on Infrastructure ENUM options for the Netherlands X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Still reading it and seems a pretty good tutorial/reference... Richard needs to forward the TISPAN/enum-wg goodies to the Speermint list (;-) -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@OEFEG.AT]=20 Sent: Tuesday, February 20, 2007 2:05 AM To: TISPAN_WG4@LIST.ETSI.ORG Subject: FW: [enum-wg] Thesis on Infrastructure ENUM options for the Netherlands All you want to know about Infrastructure ENUM Richard >=20 > http://isoc.nl/files/ScriptieLennartMaris.pdf >=20 > I have had no opportunity so far to already digest it but nonetheless=20 > wanted to share that piece of information with you. >=20 > Best regards, >=20 > Carsten Schiefner ------------------------------------------------------------------- Mail archive for TISPAN_WG4 can be browsed at the following url : http://list.etsi.org/TISPAN_WG4.html ------------------------------------------------------------------- _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Feb 24 11:50:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL04g-00016m-Sh; Sat, 24 Feb 2007 11:48:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL04g-00015r-3Z for speermint@ietf.org; Sat, 24 Feb 2007 11:48:42 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HL04e-0005h3-Pn for speermint@ietf.org; Sat, 24 Feb 2007 11:48:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] FW: [enum-wg] Thesis on Infrastructure ENUM options forthe Netherlands Date: Sat, 24 Feb 2007 17:46:00 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C81@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] FW: [enum-wg] Thesis on Infrastructure ENUM options forthe Netherlands Thread-Index: AcdU0RRiVPkI2g/+R1yWVIesYwtBhAABVbwAALwGspAAGy9x0g== References: <9BD5D7887235424FA97DFC223CAE3C28077B1804@proton.jnpr.net> From: "Stastny Richard" To: "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Richard needs to forward the TISPAN/enum-wg goodies to the Speermint = list (;-) Will do. The next TISPAN WG4 is the next week in Darnstadt =20 Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 07:00:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLeWL-0004Kz-O7; Mon, 26 Feb 2007 06:59:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLeWK-0004EU-4c for speermint@ietf.org; Mon, 26 Feb 2007 06:59:56 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLeWI-0006wI-Nc for speermint@ietf.org; Mon, 26 Feb 2007 06:59:56 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 9FF854C7CA; Mon, 26 Feb 2007 12:59:33 +0100 (CET) Date: Mon, 26 Feb 2007 12:59:33 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Selecting the right ingress point Message-ID: <20070226115933.GB8571@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org, "Livingood, Jason" References: <20070221215519.GA11690@nic.at> <45AEC6EF95942140888406588E1A6602FF7AD6@PACDCEXCMB04.cable.comcast.com> <20070223224236.GA6449@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070223224236.GA6449@nic.at> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Two clarifications: On 2007/02/23 23:02, Otmar Lendl wrote: > On 2007/02/23 21:02, "Livingood, Jason" wrote: > > > For example, you are network1. If network2 queries your ENUM server for > > a URI lookup, you want them to go to border-element-1. But if network3 > > queries you, you want them to go to border-element-2. > > Generally speaking you can make any of the mapping steps from > telephone number to IP address sensitive to the querying network: > > 1) Give different answers to ENUM queries > > 2) Give different answers to RFC 3263 NAPTR queries > > 3) Give different answers to SRV queries > > 4) Give different answers to A queries Alternatively, you can do: > 5) Slightly modify 3263 to ask different questions depending on > who's asking and/or which federation is used > > 6) Junk RFC 3263 and use other means to map SIP URI to > an ingress point. > > 7) Use something other than plain ENUM to do the number->URI mapping All these options are relevant for call-routing *within* a federation. Thus, different federations are likely to employ different methods. e.g. the typical Assisted Peering federation (Think xconnect) uses option 6: bounce all calls to a central SIP proxy of the federation (TN are trivially encoded into usernames), and that proxy answers per 3XX code with the real destination's ingress point, or just forwards to the call itself. Alternatively, a federation based on SIP over TLS, secured via certs from a central CA using the public internet does not need to deviate from RFC 3263 rules. I consider it thus to be important that this WG recognizes: * RFC 3263 is not appropriate for all types of federations * Some federations will have to find ways to make the ingress-point sender-dependent. - Speermint should offer some examples on how this can be arranged - There is no need that speermint elevates one such scheme into "This is the only way you should be doing it" status. On the other hand, the question "How does a VSP select the right federation via which to route a call?" needs a single answer. --------- Summary: * The Speermint work can be divided into two area: 1) Intra-federation "How does member VSP-A send an INVITE to fellow member VSP-B?" 2) Overall multi-hop routing: "Which peer in which federaton is my best next hop for my call to TN/URI?" * There is no need (or even point) in selecting a single solution for 1). * It is important to agree on a single algorithm for 2). My drafts (draft-lendl-speermint-federations et al) address only 2). They provide a few hints and examples of 1), but that is purely for illustrative purposes. My OpenSer code does implement a few schemes for 1). /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 09:52:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhD6-0002LD-It; Mon, 26 Feb 2007 09:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhD5-0002L3-KG for speermint@ietf.org; Mon, 26 Feb 2007 09:52:15 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLhD2-0003qB-3Z for speermint@ietf.org; Mon, 26 Feb 2007 09:52:15 -0500 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.30535065; Mon, 26 Feb 2007 09:51:49 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 09:51:49 -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: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 09:51:48 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <21FCD2BA-89B0-406B-BFA1-923A235C3187@inode.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdXua0qvgJZad+uQzan/WZ8wRfh+wB+4P2g From: "Creighton, Tom" To: "Michael Haberler" , "Andrew Newton" X-OriginalArrivalTime: 26 Feb 2007 14:51:49.0163 (UTC) FILETIME=[A4C44FB0:01C759B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I do not agree that TRIP is a viable option for the countries that support number portability. It would be the equivalent to trying to aggregate your IP routes in BGP if you allowed your customers to keep their IP addresses when they sign up for or cancel their Internet service. Simply put, it will not scale. Tom > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Friday, February 23, 2007 21:09 > To: Andrew Newton > Cc: speermint@ietf.org; Otmar Lendl > Subject: Re: [Speermint] Multihop routing >=20 >=20 > Am 23.02.2007 um 20:19 schrieb Andrew Newton: >=20 > > This sounds like RFC 3219. >=20 > yes - modulo protocol economics. >=20 > if telephone numbers or prefixes are deemed a good choice as the > primary routing key and full transitivity of the routing matrix is a > requirement, then indeed TRIP would be a solution. >=20 > our assumptions behind the Lendl federation/discovery I-D's were: >=20 > a) numbers/prefixes are needed for endpoint and/or ingress resolution > BUT they are bad choice for a routing key long term. "Private ENUM > club equals federation" is a short term fix for those buying into the > long-term downside. > b) long term the average transit path length will go down, > approaching end-to-end asymptotically. > c) full transitivity is not a requirement since the voice transit > business models don't scale to arbitrary path length in the first > place, likely less so as time progresses - note this is different > from the total connectivity promise delivered by BGP (get everywhere > cheapest according to some cost criteria) >=20 > which is why we assumed an incremental, on demand target discovery > model gets you most of the TRIP benefits at a fraction of the cost > and without number legacies. Improve it by cache priming for a near- > optimum routing and you cover lots of scenarios - like enterprise to > enterprise. >=20 > that's why I think the TRIP economics doesnt fly: important problem, > total solution, wrong primary key to solution, adoption cost not > justifiable WRT benefits. >=20 > -Michael >=20 >=20 > > > > -andy > > > > On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: > > > >> On 2007/02/20 22:02, "Livingood, Jason" > >> wrote: > >>> > >>> If you have some suggestions on how multi-hop routing and routing > >>> based > >>> on numbers should occur that is not fully addressed elsewhere, I > >>> encourage you to start up some threads on the mailing list here. I > >>> suspect other folks may be experiencing the same issues you cite, > >>> but > >>> the only way to tell is to start up discussion. > >> > >> The issue is rather simple: > >> > >> One of the basic premises of SIP is the famous end-to-end principle: > >> > >> The destination uses the DNS to publish the IP addresses of > >> its ingress elements. > >> > >> On the sender side, the call may be handed to one outbound- > >> proxy, which is independent of the destination of the call. > >> > >> Between that outbound proxy and the ingress proxy all > >> routing is pure layer3: no further SIP device is involved. > >> > >> To achieve worldwide reachability, the ingress elements of the > >> destination must accept calls from any source on the Internet. > >> > >> Almost all of the scenarios as documented by current drafts > >> in the speermint WG deviate from this model, they assume: > >> > >> * A VSP wants to control with whom he peers > >> > >> * Peering is done over private networks > >> > >> * Non-public databases are used to route calls over such > >> interconnection networks. > >> > >> * In order to complete calls to any valid destination TN/URI, > >> VSPs have to rely on the PSTN (as fall-back) and transit > >> service providers. > >> > >> --------------------- > >> > >> What does that mean for a typical call? The SIP architecture > >> assumes something like this: > >> > >> > >> /---\ /---\ ---------------- /---\ /---\ > >> |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > >> \---/ \---/ ---------------- \---/ \---/ > >> > >> whereas the speermint requirements lead to diagrams like this: > >> > >> /---\ /---\ /-----\ /-----\ /---\ /---\ > >> |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > >> \---/ \---/ \-----/ \-----/ \---/ \---/ > >> > >> (with transit VSPs involved at the SIP layer). > >> > >> > >> Real life is way more complicated: There are a lot of VSPs which > >> interconnect to each other over private links, peering fabrics, or > >> even > >> over the Internet. > >> > >> If we start to draw that as a graph with VSPs as nodes and > >> peerings as > >> edges, than we have a text-book example of a generic network. A call > >> from one side of the network to the other needs to find a path > >> through > >> this graph. Each step is a SIP peering, which could involve any > >> number > >> of layer3 hops between the SIP proxies. > >> > >> The SIP mechanisms are fine _within_ each step: The microcosmos of > >> a peering fabric looks like the Internet as envisioned by the SIP > >> standard: full L3 connectivity between participants plus a shared DNS > >> tree including an ENUM branch. > >> > >> What SIP can't do is routing between these mini-Internets. There > >> are no > >> mechnisms to choose the best of a multitude of possible paths through > >> the network of VSPs. > >> > >> That wasn't part of the design, as this is a radical departure > >> from the > >> sacred end to end principle. > >> > >> There are just two possible choices: > >> > >> * Convince the VSPs to adopt the end to end priciple and open > >> up their networks (and forget about termination fees as a side > >> effect), or > >> > >> * Be prepared to design a routing protocol on the SIP layer. > >> > >> (Compromises here don't look feasible to me, something like > >> http://en.wikipedia.org/wiki/Open_settlement_protocol might > >> be used to decouple the trust relations from connectivity, but > >> I doubt that would be enough.) > >> > >> ------------ > >> > >> Here is an analogy from a bit lower on the protocol stack: > >> > >> If you want to send an IP packet over a switched ethernet > >> infrastructure, you just need one ARP request to map IP address to > >> MAC > >> address which is used to send the packet on its way. Both sides > >> don't > >> care how many L2 switches are involved, and what version of the > >> spanning > >> tree protocol they use to build their mac-based forwarding table. > >> > >> As long as the whole network is a single broadcast domain, this works > >> fine. If you have just a few other LANs you might employ proxy ARP to > >> bridge these together. > >> > >> This band-aid is clearly insufficient once the single L2 network is > >> split up in multiple networks connected via L3 routers. ARP is still > >> fine within each segment, but a L3 routing protocol is needed to > >> maintain connectivity on the IP layer. > >> > >> Substitute as follows: > >> > >> IP layer -> SIP layer > >> IP address -> SIP URI (or Telephone number) > >> MAC address -> IP address > >> spanning tree -> BGP > >> broadcast domain-> IP layer connectivity > >> ARP -> DNS lookup to map domain to IP address > >> proxy-ARP -> announcing non-local destinations in a > >> fabric's DNS > >> > >> and thus > >> > >> L3 routing -> SIP routing > >> > >> Just as it would be ridiculous to propose to use proxy-ARP to > >> solve the > >> worldwide IP routing problem, I'd be very sceptical that one can > >> solve > >> the VoIP routing problem with minor tweaks of the RFC3263 rules. > >> > >> ------------ > >> > >> All this doesn't mean we don't need to talk about how individual > >> peering fabrics (these mini-Internets) work and what BCPs with > >> regards to SIP we need to come up with for them. > >> > >> But all that will never ever be enough to replace the PSTN > >> as THE global voice network with a SIP-based alternative. > >> > >> Comments? > >> > >> /ol > >> -- > >> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 10:03:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhNW-0002Yp-P3; Mon, 26 Feb 2007 10:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhNV-0002SH-EJ for speermint@ietf.org; Mon, 26 Feb 2007 10:03:01 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLhNR-0004zM-NC for speermint@ietf.org; Mon, 26 Feb 2007 10:03:01 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1172502176!12757385!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23616 invoked from network); 26 Feb 2007 15:02:56 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 26 Feb 2007 15:02:56 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l1QF2qeN026231; Mon, 26 Feb 2007 10:02:52 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com ([135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l1QF2dUV026076; Mon, 26 Feb 2007 10:02:47 -0500 (EST) 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: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 10:02:39 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0ED23226@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdXua0qvgJZad+uQzan/WZ8wRfh+wB+4P2gAAA/S8A= From: "PFAUTZ, PENN L, TCORP" To: "Creighton, Tom" , "Michael Haberler" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Amen! The only way TRIP can work under number portability is if we keep the whole TDM-based NP routing structure around forever. You must exchange prefix (NPA-NXX) reachability in TRIP, do an LNP query on each call to discover the routing number (LRN in the US) and then route based on the NPA-NXX of the routing number.=20 Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Creighton, Tom [mailto:Tom_Creighton@cable.comcast.com]=20 Sent: Monday, February 26, 2007 9:52 AM To: Michael Haberler; Andrew Newton Cc: speermint@ietf.org; Otmar Lendl Subject: RE: [Speermint] Multihop routing I do not agree that TRIP is a viable option for the countries that support number portability. It would be the equivalent to trying to aggregate your IP routes in BGP if you allowed your customers to keep their IP addresses when they sign up for or cancel their Internet service. Simply put, it will not scale. Tom > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Friday, February 23, 2007 21:09 > To: Andrew Newton > Cc: speermint@ietf.org; Otmar Lendl > Subject: Re: [Speermint] Multihop routing >=20 >=20 > Am 23.02.2007 um 20:19 schrieb Andrew Newton: >=20 > > This sounds like RFC 3219. >=20 > yes - modulo protocol economics. >=20 > if telephone numbers or prefixes are deemed a good choice as the > primary routing key and full transitivity of the routing matrix is a > requirement, then indeed TRIP would be a solution. >=20 > our assumptions behind the Lendl federation/discovery I-D's were: >=20 > a) numbers/prefixes are needed for endpoint and/or ingress resolution > BUT they are bad choice for a routing key long term. "Private ENUM > club equals federation" is a short term fix for those buying into the > long-term downside. > b) long term the average transit path length will go down, > approaching end-to-end asymptotically. > c) full transitivity is not a requirement since the voice transit > business models don't scale to arbitrary path length in the first > place, likely less so as time progresses - note this is different > from the total connectivity promise delivered by BGP (get everywhere > cheapest according to some cost criteria) >=20 > which is why we assumed an incremental, on demand target discovery > model gets you most of the TRIP benefits at a fraction of the cost > and without number legacies. Improve it by cache priming for a near- > optimum routing and you cover lots of scenarios - like enterprise to > enterprise. >=20 > that's why I think the TRIP economics doesnt fly: important problem, > total solution, wrong primary key to solution, adoption cost not > justifiable WRT benefits. >=20 > -Michael >=20 >=20 > > > > -andy > > > > On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote: > > > >> On 2007/02/20 22:02, "Livingood, Jason" > >> wrote: > >>> > >>> If you have some suggestions on how multi-hop routing and routing > >>> based > >>> on numbers should occur that is not fully addressed elsewhere, I > >>> encourage you to start up some threads on the mailing list here. I > >>> suspect other folks may be experiencing the same issues you cite, > >>> but > >>> the only way to tell is to start up discussion. > >> > >> The issue is rather simple: > >> > >> One of the basic premises of SIP is the famous end-to-end principle: > >> > >> The destination uses the DNS to publish the IP addresses of > >> its ingress elements. > >> > >> On the sender side, the call may be handed to one outbound- > >> proxy, which is independent of the destination of the call. > >> > >> Between that outbound proxy and the ingress proxy all > >> routing is pure layer3: no further SIP device is involved. > >> > >> To achieve worldwide reachability, the ingress elements of the > >> destination must accept calls from any source on the Internet. > >> > >> Almost all of the scenarios as documented by current drafts > >> in the speermint WG deviate from this model, they assume: > >> > >> * A VSP wants to control with whom he peers > >> > >> * Peering is done over private networks > >> > >> * Non-public databases are used to route calls over such > >> interconnection networks. > >> > >> * In order to complete calls to any valid destination TN/URI, > >> VSPs have to rely on the PSTN (as fall-back) and transit > >> service providers. > >> > >> --------------------- > >> > >> What does that mean for a typical call? The SIP architecture > >> assumes something like this: > >> > >> > >> /---\ /---\ ---------------- /---\ /---\ > >> |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC| > >> \---/ \---/ ---------------- \---/ \---/ > >> > >> whereas the speermint requirements lead to diagrams like this: > >> > >> /---\ /---\ /-----\ /-----\ /---\ /---\ > >> |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC| > >> \---/ \---/ \-----/ \-----/ \---/ \---/ > >> > >> (with transit VSPs involved at the SIP layer). > >> > >> > >> Real life is way more complicated: There are a lot of VSPs which > >> interconnect to each other over private links, peering fabrics, or > >> even > >> over the Internet. > >> > >> If we start to draw that as a graph with VSPs as nodes and > >> peerings as > >> edges, than we have a text-book example of a generic network. A call > >> from one side of the network to the other needs to find a path > >> through > >> this graph. Each step is a SIP peering, which could involve any > >> number > >> of layer3 hops between the SIP proxies. > >> > >> The SIP mechanisms are fine _within_ each step: The microcosmos of > >> a peering fabric looks like the Internet as envisioned by the SIP > >> standard: full L3 connectivity between participants plus a shared DNS > >> tree including an ENUM branch. > >> > >> What SIP can't do is routing between these mini-Internets. There > >> are no > >> mechnisms to choose the best of a multitude of possible paths through > >> the network of VSPs. > >> > >> That wasn't part of the design, as this is a radical departure > >> from the > >> sacred end to end principle. > >> > >> There are just two possible choices: > >> > >> * Convince the VSPs to adopt the end to end priciple and open > >> up their networks (and forget about termination fees as a side > >> effect), or > >> > >> * Be prepared to design a routing protocol on the SIP layer. > >> > >> (Compromises here don't look feasible to me, something like > >> http://en.wikipedia.org/wiki/Open_settlement_protocol might > >> be used to decouple the trust relations from connectivity, but > >> I doubt that would be enough.) > >> > >> ------------ > >> > >> Here is an analogy from a bit lower on the protocol stack: > >> > >> If you want to send an IP packet over a switched ethernet > >> infrastructure, you just need one ARP request to map IP address to > >> MAC > >> address which is used to send the packet on its way. Both sides > >> don't > >> care how many L2 switches are involved, and what version of the > >> spanning > >> tree protocol they use to build their mac-based forwarding table. > >> > >> As long as the whole network is a single broadcast domain, this works > >> fine. If you have just a few other LANs you might employ proxy ARP to > >> bridge these together. > >> > >> This band-aid is clearly insufficient once the single L2 network is > >> split up in multiple networks connected via L3 routers. ARP is still > >> fine within each segment, but a L3 routing protocol is needed to > >> maintain connectivity on the IP layer. > >> > >> Substitute as follows: > >> > >> IP layer -> SIP layer > >> IP address -> SIP URI (or Telephone number) > >> MAC address -> IP address > >> spanning tree -> BGP > >> broadcast domain-> IP layer connectivity > >> ARP -> DNS lookup to map domain to IP address > >> proxy-ARP -> announcing non-local destinations in a > >> fabric's DNS > >> > >> and thus > >> > >> L3 routing -> SIP routing > >> > >> Just as it would be ridiculous to propose to use proxy-ARP to > >> solve the > >> worldwide IP routing problem, I'd be very sceptical that one can > >> solve > >> the VoIP routing problem with minor tweaks of the RFC3263 rules. > >> > >> ------------ > >> > >> All this doesn't mean we don't need to talk about how individual > >> peering fabrics (these mini-Internets) work and what BCPs with > >> regards to SIP we need to come up with for them. > >> > >> But all that will never ever be enough to replace the PSTN > >> as THE global voice network with a SIP-based alternative. > >> > >> Comments? > >> > >> /ol > >> -- > >> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 10:13:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhX7-0007zr-0a; Mon, 26 Feb 2007 10:12:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhX5-0007zm-QM for speermint@ietf.org; Mon, 26 Feb 2007 10:12:55 -0500 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLhX3-0006Kb-BJ for speermint@ietf.org; Mon, 26 Feb 2007 10:12:55 -0500 Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.5134684; Mon, 26 Feb 2007 10:12:40 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 10:12:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Feb 2007 10:12:39 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602FF7AEC@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Draft IETF-68 Agenda for Review Thread-Index: AcdZt9fwxTTgHg9RTryuyEiUWJyVXw== From: "Livingood, Jason" To: X-OriginalArrivalTime: 26 Feb 2007 15:12:39.0976 (UTC) FILETIME=[8E4F3A80:01C759B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Subject: [Speermint] [wg-business] Draft IETF-68 Agenda for Review X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2020493813==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============2020493813== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C759B8.8DFB92E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C759B8.8DFB92E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached is a draft agenda for the upcoming IETF meeting in Prague. Please comment if you would like to suggest any changes. Please note that some of the URLs / file names below may not yet be valid. =20 Thanks Jason & Dave =20 =20 Session PEERing for Multimedia INTerconnect (speermint) =20 Thursday, March 22, 2007, 0900 - 1130 (Morning Session I)=20 Room Name: Congress III =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIRS: David Meyer Jason Livingood =20 SECRETARY: Alexander Mayrhofer =20 GENERAL (25 minutes) =20 1 - Welcome & Introduction to speermint / Administrivia 5 minutes Dave Meyer =20 - Mailing list: speermint-request@ietf.org subscribe =20 - Scribe (jabber) =20 - Blue Sheets =20 2 - Agenda Bashing 5 minutes Dave Meyer =20 3 - Review of Milestone Changes & Document Flow 15 minutes Jason Livingood =20 REVIEW PRIMARY WG DRAFTS (50 minutes) =20 4 - SPEERMINT Terminology Draft 10 minutes =20 http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-06. txt Dave Meyer =20 5 - IM & Presence Consolidated Use Cases 20 minutes =20 http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-pr esence-im-usecases-XX.txt Avshalom Houri =20 6 - VoIP Consolidated Use Cases 20 minutes =20 http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidat ed-usecases-00.txt Adam Uzelac =20 REVIEW NEW INDIVIDUAL DRAFTS (30 minutes) =20 7 - Enterprise Use Cases for SPEERMINT 15 minutes =20 http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us ecases-00.txt John Elwell =20 =20 8 - Directory Assistance Use Cases for SPEERMINT 15 minutes =20 http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assi stance-02.txt John Haluska =20 OPEN DISCUSSION 15 minutes =20 =20 =20 =20 ------_=_NextPart_001_01C759B8.8DFB92E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Attached is a draft=20 agenda for the upcoming IETF meeting in Prague.  Please comment if = you=20 would like to suggest any changes.  Please note that some of the = URLs /=20 file names below may not yet be valid.
 
Thanks
Jason = &=20 Dave   
 
Session PEERing for=20 Multimedia INTerconnect (speermint)
 
Thursday, March 22,=20 2007, 0900 - 1130 (Morning Session I)
Room Name: Congress=20 III
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
CHAIRS:     David = Meyer     =20  <dmm@1-4-5.net>
   =  =20 Jason Livingood   <jason_livingood@cable.c= omcast.com>
 
SECRETARY: =20 Alexander Mayrhofer <alexander.mayrhofer@nic.at= >
 

GENERAL (25 minutes)
 
1 - Welcome & Introduction to speermint / = Administrivia  =20   5 minutes
      Dave Meyer
 
   - Mailing list: speermint-request@ietf.org=
    =20 subscribe
 
   - Scribe (jabber)
  
   - = Blue=20 Sheets
 

2 - Agenda=20 Bashing           =             &= nbsp;           &n= bsp;    =20   5 minutes
      Dave Meyer
 

3 - Review of Milestone Changes & Document=20 Flow    15 minutes
 Jason Livingood
 

REVIEW PRIMARY WG DRAFTS (50 minutes)
 

4 - SPEERMINT Terminology = Draft      10=20 minutes
 http://www.ietf.org/internet-drafts/draft-ietf-speermint-term= inology-06.txt
 Dave=20 Meyer
 

5 - IM & Presence Consolidated Use = Cases    20=20 minutes
 http://www.ietf.org/internet-drafts/dra= ft-ietf-speermint-consolidated-presence-im-usecases-XX.txt
 A= vshalom=20 Houri
 

6 - VoIP Consolidated Use = Cases      20=20 minutes
 http://www.ietf.org/internet-drafts/draft-ietf= -speermint-voip-consolidated-usecases-00.txt
 Adam=20 Uzelac
 

REVIEW NEW INDIVIDUAL DRAFTS (30 minutes)
 

7 - Enterprise Use Cases for = SPEERMINT     15=20 minutes
 http://www.ietf.org/internet-drafts/draft-elwell-sp= eermint-enterprise-usecases-00.txt
 John=20 Elwell
 
 
8 - Directory Assistance Use Cases for = SPEERMINT   15=20 minutes
 http://www.ietf.org/internet-drafts/draft-haluska-s= ipping-directory-assistance-02.txt
 John=20 Haluska
 

OPEN DISCUSSION=20             &= nbsp;           &n= bsp;           &nb= sp; =20   15 minutes
  
 
 
 
------_=_NextPart_001_01C759B8.8DFB92E4-- --===============2020493813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============2020493813==-- From speermint-bounces@ietf.org Mon Feb 26 10:47:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLi48-0007Ec-Ie; Mon, 26 Feb 2007 10:47:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLi47-0007EV-SU for speermint@ietf.org; Mon, 26 Feb 2007 10:47:03 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLi45-00075s-Kb for speermint@ietf.org; Mon, 26 Feb 2007 10:47:03 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 90F314C7CB; Mon, 26 Feb 2007 16:46:52 +0100 (CET) Date: Mon, 26 Feb 2007 16:46:52 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Multihop routing Message-ID: <20070226154651.GD8571@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20070223165749.GA27574@nic.at> <477B9038-B6BA-4979-BFD4-61E8DE11EB65@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477B9038-B6BA-4979-BFD4-61E8DE11EB65@hxr.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/23 20:02, Andrew Newton wrote: > This sounds like RFC 3219. Yes, TRIP tries to address the same issue, at least for TN based routing. Actually, this is a good question for the carriers and vendors here on this list: Why hasn't TRIP seen any adoption? Is it just the scaling issues with telephone numbers as the keys? Or was this a case where neither operators nor vendors made the first step to adoption? Has anybody done an implementation at all? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 10:53:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLi9w-0004ZE-O6; Mon, 26 Feb 2007 10:53:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLi9w-0004Z9-56 for speermint@ietf.org; Mon, 26 Feb 2007 10:53:04 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLi9s-0007aA-P0 for speermint@ietf.org; Mon, 26 Feb 2007 10:53:04 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Feb 2007 10:52:29 -0500 id 015884E1.45E3023D.00002DB8 In-Reply-To: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 Message-Id: <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> From: Andrew Newton Subject: Re: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 10:52:43 -0500 To: "Creighton, Tom" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Otmar Lendl , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0171885864==" Errors-To: speermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0171885864== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-11707-1172505162-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-11707-1172505162-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote: > I do not agree that TRIP is a viable option for the countries that > support number portability. It would be the equivalent to trying to > aggregate your IP routes in BGP if you allowed your customers to keep > their IP addresses when they sign up for or cancel their Internet > service. Simply put, it will not scale. That is an interesting observation. But it begs the question, how will any multi-hop routing work with number portability then? I also wonder if this is a theoretical problem? While I understand the goal, it isn't a problem we experience today. That's not to say that nobody does multi-hop routing today, but that it is usually achieved by VSPs in very entity-specific way and not in need of inter- domain coordination. -andy --=_zeke.ecotroph.net-11707-1172505162-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Feb 26, 2007, at 9:5= 1 AM, Creighton, Tom wrote:

=

I do n= ot agree that TRIP is a viable option for the countries that

<= P style=3D"margin: 0.0px 0.0px 0.0px 0.0px">support number portability.=A0 It would be the equivalent to = trying to

aggregate y= our IP routes in BGP if you allowed your customers to keep

their IP addresses when they sign up = for or cancel their Internet

service.=A0 Simply p= ut, it will not scale.


That is an = interesting observation.=A0 But it begs the question, how will any multi-= hop routing work with number portability then?

I also wonder if this is a=A0theoretical = problem?=A0 While I understand the goal, it isn't a problem we experience = today.=A0 That's not to say that nobody does multi-hop routing today, but = that it is usually achieved by VSPs in very entity-specific way and not i= n need of inter-domain coordination.

-andy
--=_zeke.ecotroph.net-11707-1172505162-0001-2-- --===============0171885864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0171885864==-- From speermint-bounces@ietf.org Mon Feb 26 11:42:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivj-0002uW-TI; Mon, 26 Feb 2007 11:42:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivh-0002sJ-L5 for speermint@ietf.org; Mon, 26 Feb 2007 11:42:25 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLivg-0002EE-1C for speermint@ietf.org; Mon, 26 Feb 2007 11:42:25 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 26 Feb 2007 08:42:20 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208,217"; a="662605760:sNHT89643168" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] [wg-business] Draft IETF-68 Agenda for Review Date: Mon, 26 Feb 2007 11:42:19 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28077B19CB@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] Draft IETF-68 Agenda for Review Thread-Index: AcdZt9fwxTTgHg9RTryuyEiUWJyVXwADPSpg From: "Reinaldo Penno" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0925080835==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0925080835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C759C5.14D4FD3D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C759C5.14D4FD3D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should we have a few minutes to discuss routing? No, not the "open discussion" piece. An official slot where we discuss Otmar's draft in the list of routing? Maybe invite people from the SIP WG? =20 This seems to have generated more discussion than now (and in the past) than many other topics. ________________________________ From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, February 26, 2007 7:13 AM To: speermint@ietf.org Subject: [Speermint] [wg-business] Draft IETF-68 Agenda for Review =09 =09 Attached is a draft agenda for the upcoming IETF meeting in Prague. Please comment if you would like to suggest any changes. Please note that some of the URLs / file names below may not yet be valid. =20 Thanks Jason & Dave =20 =20 Session PEERing for Multimedia INTerconnect (speermint) =20 Thursday, March 22, 2007, 0900 - 1130 (Morning Session I)=20 Room Name: Congress III =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIRS: David Meyer Jason Livingood =20 SECRETARY: Alexander Mayrhofer =20 =09 GENERAL (25 minutes) =20 1 - Welcome & Introduction to speermint / Administrivia 5 minutes Dave Meyer =20 - Mailing list: speermint-request@ietf.org subscribe =20 - ScribeFrom speermint-bounces@ietf.org Mon Feb 26 11:42:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivj-0002uW-TI; Mon, 26 Feb 2007 11:42:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivh-0002sJ-L5 for speermint@ietf.org; Mon, 26 Feb 2007 11:42:25 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLivg-0002EE-1C for speermint@ietf.org; Mon, 26 Feb 2007 11:42:25 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 26 Feb 2007 08:42:20 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208,217"; a="662605760:sNHT89643168" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] [wg-business] Draft IETF-68 Agenda for Review Date: Mon, 26 Feb 2007 11:42:19 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28077B19CB@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] Draft IETF-68 Agenda for Review Thread-Index: AcdZt9fwxTTgHg9RTryuyEiUWJyVXwADPSpg From: "Reinaldo Penno" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0925080835==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0925080835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C759C5.14D4FD3D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C759C5.14D4FD3D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should we have a few minutes to discuss routing? No, not the "open discussion" piece. An official slot where we discuss Otmar's draft in the list of routing? Maybe invite people from the SIP WG? =20 This seems to have generated more discussion than now (and in the past) than many other topics. ________________________________ From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, February 26, 2007 7:13 AM To: speermint@ietf.org Subject: [Speermint] [wg-business] Draft IETF-68 Agenda for Review =09 =09 Attached is a draft agenda for the upcoming IETF meeting in Prague. Please comment if you would like to suggest any changes. Please note that some of the URLs / file names below may not yet be valid. =20 Thanks Jason & Dave =20 =20 Session PEERing for Multimedia INTerconnect (speermint) =20 Thursday, March 22, 2007, 0900 - 1130 (Morning Session I)=20 Room Name: Congress III =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIRS: David Meyer Jason Livingood =20 SECRETARY: Alexander Mayrhofer =20 =09 GENERAL (25 minutes) =20 1 - Welcome & Introduction to speermint / Administrivia 5 minutes Dave Meyer =20 - Mailing list: speermint-request@ietf.org subscribe =20 - Scribe (jabber) =20 - Blue Sheets =20 2 - Agenda Bashing 5 minutes Dave Meyer =20 3 - Review of Milestone Changes & Document Flow 15 minutes Jason Livingood =20 REVIEW PRIMARY WG DRAFTS (50 minutes) =20 4 - SPEERMINT Terminology Draft 10 minutes =09 http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-06. txt Dave Meyer =20 5 - IM & Presence Consolidated Use Cases 20 minutes =09 http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-pr esence-im-usecases-XX.txt Avshalom Houri =20 6 - VoIP Consolidated Use Cases 20 minutes =09 http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidat ed-usecases-00.txt Adam Uzelac =20 REVIEW NEW INDIVIDUAL DRAFTS (30 minutes) =20 7 - Enterprise Use Cases for SPEERMINT 15 minutes =09 http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us ecases-00.txt John Elwell =20 =20 8 - Directory Assistance Use Cases for SPEERMINT 15 minutes =09 http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assi stance-02.txt John Haluska =20 OPEN DISCUSSION 15 minutes =20 =20 =20 =20 ------_=_NextPart_001_01C759C5.14D4FD3D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Should we have a few minutes to discuss = routing? No, not=20 the "open discussion" piece. An official slot where we discuss Otmar's = draft in=20 the list of routing? Maybe invite people from the SIP = WG?
 
This seems to have generated more discussion = than now (and=20 in the past) than many other topics.

From: Livingood, Jason=20 [mailto:Jason_Livingood@cable.comcast.com]
Sent: Monday, = February=20 26, 2007 7:13 AM
To: speermint@ietf.org
Subject:=20 [Speermint] [wg-business] Draft IETF-68 Agenda for = Review

Attached is a=20 draft agenda for the upcoming IETF meeting in Prague.  Please = comment if=20 you would like to suggest any changes.  Please note that some of = the URLs=20 / file names below may not yet be valid.
 
Thanks
Jason &=20 Dave   
 
Session PEERing=20 for Multimedia INTerconnect (speermint)
 
Thursday, March=20 22, 2007, 0900 - 1130 (Morning Session I)
Room Name: Congress=20 = III
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D (jabber) =20 - Blue Sheets =20 2 - Agenda Bashing 5 minutes Dave Meyer =20 3 - Review of Milestone Changes & Document Flow 15 minutes Jason Livingood =20 REVIEW PRIMARY WG DRAFTS (50 minutes) =20 4 - SPEERMINT Terminology Draft 10 minutes =09 http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-06. txt Dave Meyer =20 5 - IM & Presence Consolidated Use Cases 20 minutes =09 http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-pr esence-im-usecases-XX.txt Avshalom Houri =20 6 - VoIP Consolidated Use Cases 20 minutes =09 http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidat ed-usecases-00.txt Adam Uzelac =20 REVIEW NEW INDIVIDUAL DRAFTS (30 minutes) =20 7 - Enterprise Use Cases for SPEERMINT 15 minutes =09 http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us ecases-00.txt John Elwell =20 =20 8 - Directory Assistance Use Cases for SPEERMINT 15 minutes =09 http://www.ietf.org/internet-drafts/draft-haluska-sipping-directory-assi stance-02.txt John Haluska =20 OPEN DISCUSSION 15 minutes =20 =20 =20 =20 ------_=_NextPart_001_01C759C5.14D4FD3D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Should we have a few minutes to discuss = routing? No, not=20 the "open discussion" piece. An official slot where we discuss Otmar's = draft in=20 the list of routing? Maybe invite people from the SIP = WG?
 
This seems to have generated more discussion = than now (and=20 in the past) than many other topics.

From: Livingood, Jason=20 [mailto:Jason_Livingood@cable.comcast.com]
Sent: Monday, = February=20 26, 2007 7:13 AM
To: speermint@ietf.org
Subject:=20 [Speermint] [wg-business] Draft IETF-68 Agenda for = Review

Attached is a=20 draft agenda for the upcoming IETF meeting in Prague.  Please = comment if=20 you would like to suggest any changes.  Please note that some of = the URLs=20 / file names below may not yet be valid.
 
Thanks
Jason &=20 Dave   
 
Session PEERing=20 for Multimedia INTerconnect (speermint)
 
Thursday, March=20 22, 2007, 0900 - 1130 (Morning Session I)
Room Name: Congress=20 = III
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
CHAIRS:     David=20 Meyer       <dmm@1-4-5.net>
   =  =20 Jason Livingood   <jason_livingood@cable.c= omcast.com>
 
SECRETARY: =20 Alexander Mayrhofer <alexander.mayrhofer@nic.at= >
 

GENERAL (25 minutes)
 
1 - Welcome & Introduction to speermint / = Administrivia  =20   5 minutes
      Dave = Meyer
 
   - Mailing list: speermint-request@ietf.org=
    =20 subscribe
 
   - Scribe (jabber)
  
   - = Blue=20 Sheets
 

2 - Agenda=20 = Bashing           =             &= nbsp;           &n= bsp;    =20   5 minutes
      Dave = Meyer
 

3 - Review of Milestone Changes & Document=20 Flow    15 minutes
 Jason Livingood
 

REVIEW PRIMARY WG DRAFTS (50 minutes)
 

4 - SPEERMINT Terminology = Draft      10=20 minutes
 http://www.ietf.org/internet-drafts/draft-ietf-speermint-term= inology-06.txt
 Dave=20 Meyer
 

5 - IM & Presence Consolidated Use=20 Cases    20 minutes
 http://www.ietf.org/internet-drafts/dra= ft-ietf-speermint-consolidated-presence-im-usecases-XX.txt
 A= vshalom=20 Houri
 

6 - VoIP Consolidated Use = Cases      20=20 minutes
 http://www.ietf.org/internet-drafts/draft-ietf= -speermint-voip-consolidated-usecases-00.txt
 Adam=20 Uzelac
 

REVIEW NEW INDIVIDUAL DRAFTS (30 minutes)
 

7 - Enterprise Use Cases for=20 SPEERMINT     15 minutes
 http://www.ietf.org/internet-drafts/draft-elwell-sp= eermint-enterprise-usecases-00.txt
 John=20 Elwell
 
 
8 - Directory Assistance Use Cases for = SPEERMINT   15=20 minutes
 http://www.ietf.org/internet-drafts/draft-haluska-s= ipping-directory-assistance-02.txt
 John=20 Haluska
 

OPEN DISCUSSION=20 =             &= nbsp;  &nb=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
CHAIRS:     David=20 Meyer       <dmm@1-4-5.net>
   =  =20 Jason Livingood   <jason_livingood@cable.c= omcast.com>
 
SECRETARY: =20 Alexander Mayrhofer <alexander.mayrhofer@nic.at= >
 

GENERAL (25 minutes)
 
1 - Welcome & Introduction to speermint / = Administrivia  =20   5 minutes
      Dave = Meyer
 
   - Mailing list: speermint-request@ietf.org=
    =20 subscribe
 
   - Scribe (jabber)
  
   - = Blue=20 Sheets
 

2 - Agenda=20 = Bashing           =             &= nbsp;           &n= bsp;    =20   5 minutes
      Dave = Meyer
 

3 - Review of Milestone Changes & Document=20 Flow    15 minutes
 Jason Livingood
 

REVIEW PRIMARY WG DRAFTS (50 minutes)
 

4 - SPEERMINT Terminology = Draft      10=20 minutes
 http://www.ietf.org/internet-drafts/draft-ietf-speermint-term= inology-06.txt
 Dave=20 Meyer
 

5 - IM & Presence Consolidated Use=20 Cases    20 minutes
 http://www.ietf.org/internet-drafts/dra= ft-ietf-speermint-consolidated-presence-im-usecases-XX.txt
 A= vshalom=20 Houri
 

6 - VoIP Consolidated Use = Cases      20=20 minutes
 http://www.ietf.org/internet-drafts/draft-ietf= -speermint-voip-consolidated-usecases-00.txt
 Adam=20 Uzelac
 

REVIEW NEW INDIVIDUAL DRAFTS (30 minutes)
 

7 - Enterprise Use Cases for=20 SPEERMINT     15 minutes
 http://www.ietf.org/internet-drafts/draft-elwell-sp= eermint-enterprise-usecases-00.txt
 John=20 Elwell
 
 
8 - Directory Assistance Use Cases for = SPEERMINT   15=20 minutes
 http://www.ietf.org/internet-drafts/draft-haluska-s= ipping-directory-assistance-02.txt
 John=20 Haluska
 

OPEN DISCUSSION=20 =             &= nbsp;           &n= bsp;           &nb= sp; =20   15 minutes
  
 
 
 
------_=_NextPart_001_01C759C5.14D4FD3D-- --===============0925080835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0925080835==-- From speermint-bounces@ietf.org Mon Feb 26 11:42:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivr-00030r-C5; Mon, 26 Feb 2007 11:42:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivq-00030m-Oo for speermint@ietf.org; Mon, 26 Feb 2007 11:42:34 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLivp-0002FE-BE for speermint@ietf.org; Mon, 26 Feb 2007 11:42:34 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B49C84C7CC; Mon, 26 Feb 2007 17:42:30 +0100 (CET) Date: Mon, 26 Feb 2007 17:42:30 +0100 From: Otmar Lendl To: Andrew Newton Subject: Re: [Speermint] Multihop routing Message-ID: <20070226164230.GE8571@nic.at> Mail-Followup-To: Otmar Lendl , Andrew Newton , "Creighton, Tom" , Michael Haberler , speermint@ietf.org References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: speermint@ietf.org, "Creighton, Tom" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/26 16:02, Andrew Newton wrote: > > On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote: > > >I do not agree that TRIP is a viable option for the countries that > >support number portability. It would be the equivalent to trying to > >aggregate your IP routes in BGP if you allowed your customers to keep > >their IP addresses when they sign up for or cancel their Internet > >service. Simply put, it will not scale. > > That is an interesting observation. But it begs the question, how > will any multi-hop routing work with number portability then? > By adding a mapping operation in front of the routing protocol. Consider email: it would be pointless to create a routing protocol for email which is keyed on domains. The number of domains is huge and there is no way to aggregate these. The solution there is to use the DNS to map domains to the IP-addresses of the mail-servers. These can be aggregated and are suitable as keys for routing protocols. We probably need to do the same for this problem: * Use a directory lookup to map TNs to other identifiers which are better suited for a routing protocol. * Build a routing protocol on top of these identifiers. -------- My sp;        &n= bsp;           &nb= sp; =20   15 minutes
  
 
 
 
------_=_NextPart_001_01C759C5.14D4FD3D-- --===============0925080835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0925080835==-- From speermint-bounces@ietf.org Mon Feb 26 11:42:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivr-00030r-C5; Mon, 26 Feb 2007 11:42:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLivq-00030m-Oo for speermint@ietf.org; Mon, 26 Feb 2007 11:42:34 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLivp-0002FE-BE for speermint@ietf.org; Mon, 26 Feb 2007 11:42:34 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B49C84C7CC; Mon, 26 Feb 2007 17:42:30 +0100 (CET) Date: Mon, 26 Feb 2007 17:42:30 +0100 From: Otmar Lendl To: Andrew Newton Subject: Re: [Speermint] Multihop routing Message-ID: <20070226164230.GE8571@nic.at> Mail-Followup-To: Otmar Lendl , Andrew Newton , "Creighton, Tom" , Michael Haberler , speermint@ietf.org References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: speermint@ietf.org, "Creighton, Tom" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/26 16:02, Andrew Newton wrote: > > On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote: > > >I do not agree that TRIP is a viable option for the countries that > >support number portability. It would be the equivalent to trying to > >aggregate your IP routes in BGP if you allowed your customers to keep > >their IP addresses when they sign up for or cancel their Internet > >service. Simply put, it will not scale. > > That is an interesting observation. But it begs the question, how > will any multi-hop routing work with number portability then? > By adding a mapping operation in front of the routing protocol. Consider email: it would be pointless to create a routing protocol for email which is keyed on domains. The number of domains is huge and there is no way to aggregate these. The solution there is to use the DNS to map domains to the IP-addresses of the mail-servers. These can be aggregated and are suitable as keys for routing protocols. We probably need to do the same for this problem: * Use a directory lookup to map TNs to other identifiers which are better suited for a routing protocol. * Build a routing protocol on top of these identifiers. -------- My proposals (draft-lendl-domain-policy-ddds-02 + draft-lendl-speermint-federations-03) propose to use - I-ENUM to map TN to SIP URIs - a DDDS application to map the domain part of those URIs to federation identifiers - Route based on the federation IDs. (in the best case: just route via a shared federation) You could save one step by storing the federation IDs directly in I-ENUM, but you loose the possibility to do URI-based calls with the same framework. > I also wonder if this is a theoretical problem? While I understand > the goal, it isn't a problem we experience today. That's not to say > that nobody does multi-hop routing today, but that it is usually > achieved by VSPs in very entity-specific way and not in need of inter- > domain coordination. Right now, we're seeing a lot of ad-hoc peering with hand-spun route advertisements. Whatever transit traffic is currently passed via SIP, the routing seems to be mainly done via manual, static routes. If we ever want to get rid of the PSTN as the "default route" to be uses when the destination isn't a peer of the source network, then we need an automatic routing protocol which supports transit networks. Whether that is within the speermint charter, is open for discussion. I don't doubt that we need somethings like this in the long run. Even the NGN guys & gals over in the ITU/ETSI/3GPP world are facing the same problem and as far as I know, they haven't found the magic bullet yet. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint proposals (draft-lendl-domain-policy-ddds-02 + draft-lendl-speermint-federations-03) propose to use - I-ENUM to map TN to SIP URIs - a DDDS application to map the domain part of those URIs to federation identifiers - Route based on the federation IDs. (in the best case: just route via a shared federation) You could save one step by storing the federation IDs directly in I-ENUM, but you loose the possibility to do URI-based calls with the same framework. > I also wonder if this is a theoretical problem? While I understand > the goal, it isn't a problem we experience today. That's not to say > that nobody does multi-hop routing today, but that it is usually > achieved by VSPs in very entity-specific way and not in need of inter- > domain coordination. Right now, we're seeing a lot of ad-hoc peering with hand-spun route advertisements. Whatever transit traffic is currently passed via SIP, the routing seems to be mainly done via manual, static routes. If we ever want to get rid of the PSTN as the "default route" to be uses when the destination isn't a peer of the source network, then we need an automatic routing protocol which supports transit networks. Whether that is within the speermint charter, is open for discussion. I don't doubt that we need somethings like this in the long run. Even the NGN guys & gals over in the ITU/ETSI/3GPP world are facing the same problem and as far as I know, they haven't found the magic bullet yet. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 12:01:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjDL-0007fx-4W; Mon, 26 Feb 2007 12:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjDJ-0007fR-S7 for speermint@ietf.org; Mon, 26 Feb 2007 12:00:37 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjD6-0004di-I4 for speermint@ietf.org; Mon, 26 Feb 2007 12:00:37 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Feb 2007 11:54:44 -0500 id 015884BD.45E310D4.00003B61 In-Reply-To: <20070226164230.GE8571@nic.at> References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> <20070226164230.GE8571@nic.at> 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: Andrew Newton Subject: Re: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 11:54:58 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: speermint@ietf.org, "Creighton, Tom" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Feb 26, 2007, at 11:42 AM, Otmar Lendl wrote: > Consider email: it would be pointless to create a routing protocol for > email which is keyed on domains. The number of domains is huge and > there > is no way to aggregate these. The solution there is to use the DNS to > map domains to the IP-addresses of the mail-servers. These can be > aggregated and are suitable as keys for routing protocols. > > We probably need to do the same for this problem: > > * Use a directory lookup to map TNs to other identifiers which > are better suited for a routing protocol. Once you've done this, you are exactly at the point of an Internet email model. > * Build a routing protocol on top of these identifiers. Do Internet email providers relay email through each other day? No. In fact, relaying is not considered good practice anymore. I think this will work even worse with SIP. > -------- > > My proposals (draft-lendl-domain-policy-ddds-02 + > draft-lendl-speermint-federations-03) propose to use > > - I-ENUM to map TN to SIP URIs [..snip..] > If we ever want to get rid of the PSTN as the "default route" to be > uses when the destination isn't a peer of the source network, then > we need an automatic routing protocol which supports transit networks. There is a disconnect here with stating a goal of getting rid of the PSTN by using I-ENUM. As far as I can tell, the entire purpose of I- ENUM is about the incumbent PSTN players retaining their strict control. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 12:07:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjJA-0001vF-Qn; Mon, 26 Feb 2007 12:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjJ8-0001q8-Vl for speermint@ietf.org; Mon, 26 Feb 2007 12:06:38 -0500 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjJ6-0005YE-CR for speermint@ietf.org; Mon, 26 Feb 2007 12:06:38 -0500 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JE200A9GXT7IF@firewall.mci.com> for speermint@ietf.org; Mon, 26 Feb 2007 16:58:19 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([127.0.0.1]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JE200LDZXT7RW@dgismtp03.mcilink.com> for speermint@ietf.org; Mon, 26 Feb 2007 16:58:19 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([153.39.68.168]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JE200LBBXT665@dgismtp03.mcilink.com> for speermint@ietf.org; Mon, 26 Feb 2007 16:58:19 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 16:58:18 +0000 Date: Mon, 26 Feb 2007 16:58:17 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Speermint] Multihop routing In-reply-to: <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> To: speermint@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Speermint] Multihop routing Thread-index: AcdZvlteKEaiKUa8RgWBnWfqQARC4AABb/0w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Feb 2007 16:58:18.0798 (UTC) FILETIME=[508AB4E0:01C759C7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618899241==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1618899241== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C759C7.505DE548" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C759C7.505DE548 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Isn't any issue relating to telephone numbers, an ENUM issue? =20 =20 It does seem to me that [infrastructure] ENUM, if it does this successfully, is effectively a global LNP system. Maybe people are questioning whether that will succeed? While I can be as skeptical as the next guy, I'm struggling to understand how this has become a speermint issue. =20 tim =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Monday, February 26, 2007 9:53 AM To: Creighton, Tom Cc: Otmar Lendl; speermint@ietf.org Subject: Re: [Speermint] Multihop routing =09 =09 On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote: I do not agree that TRIP is a viable option for the countries that support number portability. It would be the equivalent to trying to aggregate your IP routes in BGP if you allowed your customers to keep their IP addresses when they sign up for or cancel their Internet service. Simply put, it will not scale. That is an interesting observation. But it begs the question, how will any multi-hop routing work with number portability then? I also wonder if this is a theoretical problem? While I understand the goal, it isn't a problem we experience today. That's not to say that nobody does multi-hop routing today, but that it is usually achieved by VSPs in very entity-specific way and not in need of inter-domain coordination. -andy ------_=_NextPart_001_01C759C7.505DE548 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Isn't any issue relating to telephone numbers, = an ENUM=20 issue?  
 
It does seem to me that [infrastructure] = ENUM, if it=20 does this successfully, is effectively a global LNP system.  Maybe = people=20 are questioning whether that will succeed?  While I can be as = skeptical as=20 the next guy, I'm struggling to understand how this has become a = speermint=20 issue.
 
tim
 

From: Andrew Newton = [mailto:andy@hxr.us]=20
Sent: Monday, February 26, 2007 9:53 AM
To: = Creighton,=20 Tom
Cc: Otmar Lendl; speermint@ietf.org
Subject: = Re:=20 [Speermint] Multihop routing


On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote:

I do not agree that TRIP is a viable option for the = countries=20 that

support number portability. =20 It would be the equivalent to trying to

aggregate your IP routes in BGP if you allowed your = customers to=20 keep

their IP addresses when they sign up for or cancel their=20 Internet

service.  = Simply put,=20 it will not scale.


That is an interesting observation.  But it begs the = question, how=20 will any multi-hop routing work with number portability then?

I also wonder if this is a theoretical problem?  While = I=20 understand the goal, it isn't a problem we experience today.  = That's not=20 to say that nobody does multi-hop routing today, but that it is = usually=20 achieved by VSPs in very entity-specific way and not in need of = inter-domain=20 coordination.

-andy
------_=_NextPart_001_01C759C7.505DE548-- --===============1618899241== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1618899241==-- From speermint-bounces@ietf.org Mon Feb 26 12:10:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjMq-00071k-6U; Mon, 26 Feb 2007 12:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjMo-000714-Lm for speermint@ietf.org; Mon, 26 Feb 2007 12:10:26 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLjMn-0005xe-DX for speermint@ietf.org; Mon, 26 Feb 2007 12:10:26 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1172509777!10169866!155 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20492 invoked from network); 26 Feb 2007 17:10:19 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 26 Feb 2007 17:10:19 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l1QG21fb002488; Mon, 26 Feb 2007 11:02:02 -0500 (EST) Received: from ACCLUST02EVS1.ugd.att.com (acst04.ugd.att.com [135.37.16.9]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l1QG1ujM002413; Mon, 26 Feb 2007 11:01:56 -0500 (EST) 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: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 11:01:55 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0ED23373@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <20070226154651.GD8571@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdZve8+Ls3hi+A8RpucV29RRtwfoAAALUww From: "PFAUTZ, PENN L, TCORP" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Beyond number portability and scaling, TRIP presents a number of other issues that prevent its wide deployment. Among these are... Most telephone numbers are still not reachable via IP and most thus also require somebody pay intercarrier compensation. Under these circumstances, who's going to advertise reachability to numbers without commercial arrangements? And where those arrangements have been negotiated, TRIP may not be necessary. =20 Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Monday, February 26, 2007 10:47 AM To: speermint@ietf.org Subject: Re: [Speermint] Multihop routing On 2007/02/23 20:02, Andrew Newton wrote: > This sounds like RFC 3219. Yes, TRIP tries to address the same issue, at least for TN based routing. Actually, this is a good question for the carriers and vendors here on this list: Why hasn't TRIP seen any adoption? Is it just the scaling issues with telephone numbers as the keys? Or was this a case where neither operators nor vendors made the first step to adoption? Has anybody done an implementation at all? /ol --=20 < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 13:53:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkwX-0000cL-Aq; Mon, 26 Feb 2007 13:51:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkwW-0000c9-Q6 for speermint@ietf.org; Mon, 26 Feb 2007 13:51:24 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLkwT-0002eo-K8 for speermint@ietf.org; Mon, 26 Feb 2007 13:51:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 19:48:06 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C82@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdZvlteKEaiKUa8RgWBnWfqQARC4AABb/0wAASi5NY= References: From: "Stastny Richard" To: "Dwight, Timothy M \(Tim\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Excactly =20 I-ENUM is out of scope in Speermint =20 I have really no idea why everybody is talking about phone numbers =20 The task of speermint is to solve interconnection based on URIs =20 We have to keep this separate =20 Richard ________________________________ Von: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com] Gesendet: Mo 26.02.2007 17:58 An: speermint@ietf.org Betreff: RE: [Speermint] Multihop routing Isn't any issue relating to telephone numbers, an ENUM issue? =20 =20 It does seem to me that [infrastructure] ENUM, if it does this = successfully, is effectively a global LNP system. Maybe people are = questioning whether that will succeed? While I can be as skeptical as = the next guy, I'm struggling to understand how this has become a = speermint issue. =20 tim =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Monday, February 26, 2007 9:53 AM To: Creighton, Tom Cc: Otmar Lendl; speermint@ietf.org Subject: Re: [Speermint] Multihop routing =09 =09 On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote: I do not agree that TRIP is a viable option for the countries that support number portability. It would be the equivalent to trying to aggregate your IP routes in BGP if you allowed your customers to keep their IP addresses when they sign up for or cancel their Internet service. Simply put, it will not scale. That is an interesting observation. But it begs the question, how will = any multi-hop routing work with number portability then? I also wonder if this is a theoretical problem? While I understand the = goal, it isn't a problem we experience today. That's not to say that = nobody does multi-hop routing today, but that it is usually achieved by = VSPs in very entity-specific way and not in need of inter-domain = coordination. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 17:06:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnyJ-0004b8-VB; Mon, 26 Feb 2007 17:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnyI-0004Zp-Cn for speermint@ietf.org; Mon, 26 Feb 2007 17:05:26 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLny7-0006fy-A3 for speermint@ietf.org; Mon, 26 Feb 2007 17:05:26 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id AF6904C7CE; Mon, 26 Feb 2007 23:05:10 +0100 (CET) Date: Mon, 26 Feb 2007 23:05:10 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Multihop routing Message-ID: <20070226220510.GB32057@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/26 17:02, "Dwight, Timothy M (Tim)" wrote: > Isn't any issue relating to telephone numbers, an ENUM issue? Not quite. Some people do TN -> SIP nexthop lookup with SIP 3xx responses. > It does seem to me that [infrastructure] ENUM, if it does this > successfully, is effectively a global LNP system. Maybe people are > questioning whether that will succeed? While I can be as skeptical as > the next guy, I'm struggling to understand how this has become a > speermint issue. Speermint isn't going to deal with I-ENUM. The range of potential speermint solutions just changes if you can assume a working I-ENUM infrastructure. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 20:24:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLr3e-0007Dh-Q6; Mon, 26 Feb 2007 20:23:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLr2Q-0006Pz-9B for speermint@ietf.org; Mon, 26 Feb 2007 20:21:54 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLnpr-0000xo-Vw for speermint@ietf.org; Mon, 26 Feb 2007 16:56:48 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 326614C7CE; Mon, 26 Feb 2007 22:56:43 +0100 (CET) Date: Mon, 26 Feb 2007 22:56:43 +0100 From: Otmar Lendl To: Andrew Newton Subject: Re: [Speermint] Multihop routing Message-ID: <20070226215643.GA32057@nic.at> Mail-Followup-To: Otmar Lendl , Andrew Newton , "Creighton, Tom" , Michael Haberler , speermint@ietf.org References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> <20070226164230.GE8571@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 1.2 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: speermint@ietf.org, "Creighton, Tom" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/26 17:02, Andrew Newton wrote: > > On Feb 26, 2007, at 11:42 AM, Otmar Lendl wrote: > >Consider email: it would be pointless to create a routing protocol for > >email which is keyed on domains. The number of domains is huge and > >there > >is no way to aggregate these. The solution there is to use the DNS to > >map domains to the IP-addresses of the mail-servers. These can be > >aggregated and are suitable as keys for routing protocols. > > > >We probably need to do the same for this problem: > > > >* Use a directory lookup to map TNs to other identifiers which > > are better suited for a routing protocol. > > Once you've done this, you are exactly at the point of an Internet > email model. No. On two counts: * I don't think we should map TNs to IP-addresses * The "email model" has not only technical connotations, it also describes an ecosystem. The basic premise is that anybody can connect to a mail server which is listed in a MX record for a domain and transmit mails addressed to that domain. No questions asked, no contacts signed, no money exchanged. That is not how the ecosystem of the phone business works. Nothing that speermint can do is going to change that in the short term. > >* Build a routing protocol on top of these identifiers. > > Do Internet email providers relay email through each other day? No. > In fact, relaying is not considered good practice anymore. I think > this will work even worse with SIP. Right now, the huge majority of carriers will only accept calls via SIP to their customers if they get money for every call. If they reject the call, then the originating network must fall back to the PSTN which completes the call and arranges for the destination network to get paid. Thus there is _no_ motivation for carriers to allow anonymous SIP proxies to places calls to their customers, as "no business relationship" implies "no termination fee". In theory, every VSP could establish such a business relationship with every other VSP in the world. Thus everybody has a peering relationship with everybody else, everybody is happy and not even the happy tree friends get hurt. That just doesn't scale. There is no benefit for a small Korean VoIP operator to enter into a contract with a small VoIP service in Tyrol. The number of calls between those two will in all likelihood be zero. There is thus a market for aggregators. For carriers to act as transit networks to take the sting out of the O(n*n) scaling of a full mesh. Yes, transit networks (relays) make little sense for email. They do make sense for PSTN-replacement SIP, as they act as * Payment aggregators See above. * Trust proxies If my users complain about nuisance call, SPIT, stalking, .. I have a contract with the party from whom I received those calls. I can hold them accountable for the behavior of their users. * DoS protection If I just need to open my ingress elements to a known set of transit carriers and peers, it is a lot simpler to protect them against DoS attacks. * SIP compatibility Given the state of SIP implementations these days, such aggregators also have a role to get consistent performance and features. (Yes, it's that bad. Just the other day I had to debug an issue with a German operator which insisted to route calls based on the To: header instead of the request URI. I've run into enough issues with SIP enabled PBXs which don't do call-transfers correctsly when called directly via SIP and not via their PSTN gateway. I'm sure Eli can tell you some more riveting stories about the quality of SIP implementations.) I see zero chance that the carrier world moves to an email-style interconnection regime within the next decade. I'd be pleasantly surprised if the guys from AT&T, Global Crossing, L3 & co prove me wrong on this. Adam? Penn? Daryl? > >If we ever want to get rid of the PSTN as the "default route" to be > >uses when the destination isn't a peer of the source network, then we > >need an automatic routing protocol which supports transit networks. > > There is a disconnect here with stating a goal of getting rid of the > PSTN by using I-ENUM. As far as I can tell, the entire purpose of > I- ENUM is about the incumbent PSTN players retaining their strict > control. I-ENUM is for carriers to help them move from SS7 to SIP. That does not mean the business foundations change dramatically. User ENUM has the potential to wrestle control from carriers (especially for corporate users). Btw, what's keeping the NANP from implementing it? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 20:35:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLrFL-00044y-JI; Mon, 26 Feb 2007 20:35:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLrEL-0003yW-Tg for speermint@ietf.org; Mon, 26 Feb 2007 20:34:13 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLrEJ-0006AK-MS for speermint@ietf.org; Mon, 26 Feb 2007 20:34:13 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Feb 2007 20:33:41 -0500 id 0158811A.45E38A75.00004CAC In-Reply-To: <20070226215643.GA32057@nic.at> References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> <20070226164230.GE8571@nic.at> <20070226215643.GA32057@nic.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93ACE2DE-66FA-465E-9150-69F006B1037E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 20:33:59 -0500 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: speermint@ietf.org, "Creighton, Tom" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Feb 26, 2007, at 4:56 PM, Otmar Lendl wrote: >> Once you've done this, you are exactly at the point of an Internet >> email model. > > No. On two counts: > > * I don't think we should map TNs to IP-addresses DNS does not map email addresses to IP addresses. It maps email domains to IP addresses. The connection model you are describing is the same. But you are right that VSPs are much, much more restrictive from whom they will accept traffic. > There is thus a market for aggregators. For carriers to act as > transit networks to take the sting out of the O(n*n) scaling of > a full mesh. I'm well aware of these players. I've personally talked to most of them at one time or another. Perhaps they are in need of multi-hop routing between their respective domains, but that class of problem is not the entirety of the space. And I'm unaware why TRIP couldn't be used to satisfy their needs. Perhaps NP is an issue, but I don't see how an extra layer of indirection helps in that case. > I see zero chance that the carrier world moves to an email-style > interconnection regime within the next decade. I'd be pleasantly > surprised if the guys from AT&T, Global Crossing, L3 & co prove me > wrong on this. Adam? Penn? Daryl? FYI... not all VSPs are the carrier-of-record. >> There is a disconnect here with stating a goal of getting rid of the >> PSTN by using I-ENUM. As far as I can tell, the entire purpose of >> I- ENUM is about the incumbent PSTN players retaining their strict >> control. > > I-ENUM is for carriers to help them move from SS7 to SIP. That does > not mean the business foundations change dramatically. Thanks for verifying my assumption. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Feb 26 20:49:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLrSz-0000FW-Ds; Mon, 26 Feb 2007 20:49:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLrRS-00082I-DT for speermint@ietf.org; Mon, 26 Feb 2007 20:47:46 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLrRR-0008Di-7D for speermint@ietf.org; Mon, 26 Feb 2007 20:47:46 -0500 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Feb 2007 20:47:22 -0500 id 0158811A.45E38DAA.00005064 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C82@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4C82@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Speermint] Multihop routing Date: Mon, 26 Feb 2007 20:47:40 -0500 To: Stastny Richard X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0976402150==" Errors-To: speermint-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0976402150== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-20583-1172540842-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-20583-1172540842-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Feb 26, 2007, at 1:48 PM, Stastny Richard wrote: > The task of speermint is to solve interconnection based on URIs Oh. Ok. Can we get a show of hands from the VSPs who start and base routing only on URIs? -andy --=_zeke.ecotroph.net-20583-1172540842-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Feb 26, 2007, at 1:4= 8 PM, Stastny Richard wrote:

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">The t= ask of speermint is to solve interconnection based on URIs


Oh.=A0 Ok.=A0 Can we get a show of hands from th= e VSPs who start and base routing only on URIs?

-andy
--=_zeke.ecotroph.net-20583-1172540842-0001-2-- --===============0976402150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0976402150==-- From speermint-bounces@ietf.org Tue Feb 27 07:07:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM16i-0007BB-0y; Tue, 27 Feb 2007 07:07:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM16g-0007Ao-PK for speermint@ietf.org; Tue, 27 Feb 2007 07:06:58 -0500 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM0Sh-00076S-Fo for speermint@ietf.org; Tue, 27 Feb 2007 06:25:40 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id C4EAC4C7D2; Tue, 27 Feb 2007 12:25:38 +0100 (CET) Date: Tue, 27 Feb 2007 12:25:38 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Multihop routing Message-ID: <20070227112538.GB15230@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com> <977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us> <20070226164230.GE8571@nic.at> <20070226215643.GA32057@nic.at> <93ACE2DE-66FA-465E-9150-69F006B1037E@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93ACE2DE-66FA-465E-9150-69F006B1037E@hxr.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/02/27 02:02, Andrew Newton wrote: > On Feb 26, 2007, at 4:56 PM, Otmar Lendl wrote: > > >There is thus a market for aggregators. For carriers to act as > >transit networks to take the sting out of the O(n*n) scaling of > >a full mesh. > > I'm well aware of these players. I've personally talked to most of > them at one time or another. Perhaps they are in need of multi-hop > routing between their respective domains, but that class of problem > is not the entirety of the space. And I'm unaware why TRIP couldn't > be used to satisfy their needs. Perhaps NP is an issue, but I don't > see how an extra layer of indirection helps in that case. It reduces the complexity of the routing problem from O(#numbers) to O(#carriers). I don't have the statistics for the US market, but I guess that means going from a few hundred millions down to a few thousands. That are five orders of magnitude. > >I see zero chance that the carrier world moves to an email-style > >interconnection regime within the next decade. I'd be pleasantly > >surprised if the guys from AT&T, Global Crossing, L3 & co prove me > >wrong on this. Adam? Penn? Daryl? > > FYI... not all VSPs are the carrier-of-record. In the US. Things are different in other countries. e.g. in Austria even a small VoIP operator gets his numbers directly from the regulatory authority. He will likely contract some larger operator to arrange for the routing inside the PSTN, but he owns the numbers and thus controls the I-ENUM entries. For the US, there might be a case for two variations of I-ENUM, one which mirrors the LERG, and a second where the Vonages & co can make their entries. (Adding that tree would be trivial using the short-term proposal for combined i-enum. But that's a topic for the ENUM wg.) > >>There is a disconnect here with stating a goal of getting rid of the > >>PSTN by using I-ENUM. As far as I can tell, the entire purpose of > >>I- ENUM is about the incumbent PSTN players retaining their strict > >>control. > > > >I-ENUM is for carriers to help them move from SS7 to SIP. That does > >not mean the business foundations change dramatically. > > Thanks for verifying my assumption. Interestingly enough, Richard Shockey talks a lot about I-ENUM defining new "business relationships" and "carrier business rules or carrier to carrier business structures" in http://www1.ietf.org/mail-archive/web/enum/current/msg05529.html You thus should not rely on my word. I recommend you contact our esteemed ENUM WG chair and cross-check your assumptions with him. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 27 10:37:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4NX-0001h6-GV; Tue, 27 Feb 2007 10:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4NV-0001bP-Sp for speermint@ietf.org; Tue, 27 Feb 2007 10:36:33 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4NT-0003m8-8b for speermint@ietf.org; Tue, 27 Feb 2007 10:36:33 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id C3282E8B02; Tue, 27 Feb 2007 10:36:00 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:36:00 -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: [Speermint] Multihop routing Date: Tue, 27 Feb 2007 10:35:59 -0500 Message-ID: In-Reply-To: <20070227112538.GB15230@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdaaF4IMhJIDbySRCeyOka2MckUNwAEVsoA References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com><977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us><20070226164230.GE8571@nic.at><20070226215643.GA32057@nic.at><93ACE2DE-66FA-465E-9150-69F006B1037E@hxr.us> <20070227112538.GB15230@nic.at> From: "Uzelac, Adam" To: "Otmar Lendl" , X-OriginalArrivalTime: 27 Feb 2007 15:36:00.0480 (UTC) FILETIME=[FB7CEE00:01C75A84] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Though ENUM is certainly out of scope, there needs to be an acknowledgement that ENUM does, can and, as it's being argued in the thread, should be a lively topic for SIP Peering in general. I don't see any harm in delving into the topic on here. From a macro-level point of view, ENUM needs to be acknowledged and understood in conjunction to the SPEERMINT-specific charter items. As it pertains to I-ENUM and peering, I believe the ultimate end for the most effective SIP Peering model necessitates I-ENUM. It's another matter entirely if the goal is achievable. A model with I-ENUM, DDDS, SIP policy, etc =3D = is really the only way to offer a well-balanced solution for those with consumer, commercial and practical interests at heart. =20 -AU > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Tuesday, February 27, 2007 6:26 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Multihop routing >=20 >=20 > Interestingly enough, Richard Shockey talks a lot about=20 > I-ENUM defining new "business relationships" and "carrier=20 > business rules or carrier to carrier business structures" in=20 > http://www1.ietf.org/mail-archive/web/enum/current/msg05529.html >=20 > You thus should not rely on my word. I recommend you contact=20 > our esteemed ENUM WG chair and cross-check your assumptions with him. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Feb 27 10:51:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4by-00024U-Ad; Tue, 27 Feb 2007 10:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4bx-00022i-Br for speermint@ietf.org; Tue, 27 Feb 2007 10:51:29 -0500 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4br-0005ld-Tc for speermint@ietf.org; Tue, 27 Feb 2007 10:51:29 -0500 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.1179470; Tue, 27 Feb 2007 10:51:00 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:51:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Multihop routing Date: Tue, 27 Feb 2007 10:50:58 -0500 Message-ID: <45AEC6EF95942140888406588E1A6602F76F02@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdZvlteKEaiKUa8RgWBnWfqQARC4AABb/0wADBjSrA= From: "Lee, Yiu" To: "Dwight, Timothy M \(Tim\)" , X-OriginalArrivalTime: 27 Feb 2007 15:51:00.0424 (UTC) FILETIME=[13E57C80:01C75A87] X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0668959148==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0668959148== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75A87.13952D56" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75A87.13952D56 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I got a little bit confused. In Speermint, we are talking about routing sip-uri, so this is about routing domain. Imagine we have an enum database that can match every tn to sip-uri. For outbound traffic, you will have full control inside your domain. For inbound traffic, you can publish the border element to dns to control which element you want the inbound traffic to enter to your domain. In federation, you can ask your VSP to publish your domain to point to their border elements. If you really want to give a different view of your border elements to different VSPs, then you may want to create different ENUM views to different VSPs. We don't need a routing protocol to handle emails, so neither do we. ________________________________ From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizon.com]=20 Sent: Monday, February 26, 2007 11:58 AM To: speermint@ietf.org Subject: RE: [Speermint] Multihop routing Isn't any issue relating to telephone numbers, an ENUM issue? =20 =20 It does seem to me that [infrastructure] ENUM, if it does this successfully, is effectively a global LNP system. Maybe people are questioning whether that will succeed? While I can be as skeptical as the next guy, I'm struggling to understand how this has become a speermint issue. =20 tim =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Monday, February 26, 2007 9:53 AM To: Creighton, Tom Cc: Otmar Lendl; speermint@ietf.org Subject: Re: [Speermint] Multihop routing =09 =09 On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote: I do not agree that TRIP is a viable option for the countries that support number portability. It would be the equivalent to trying to aggregate your IP routes in BGP if you allowed your customers to keep their IP addresses when they sign up for or cancel their Internet service. Simply put, it will not scale. That is an interesting observation. But it begs the question, how will any multi-hop routing work with number portability then? I also wonder if this is a theoretical problem? While I understand the goal, it isn't a problem we experience today. That's not to say that nobody does multi-hop routing today, but that it is usually achieved by VSPs in very entity-specific way and not in need of inter-domain coordination. -andy ------_=_NextPart_001_01C75A87.13952D56 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I got a little bit confused. In = Speermint, we are=20 talking about routing sip-uri, so this is about routing = domain. Imagine we have an enum database that can match every tn to = sip-uri. For=20 outbound traffic, you will have full control=20 inside your domain. For inbound traffic, you can publish the = border=20 element to dns to control which element = you want the inbound traffic to enter=20 to your domain. In = federation,=20 you can ask your VSP to publish your domain to point to their border = elements.=20 If you really want to give a different view of your border elements to = different=20 VSPs, then you may want to create different ENUM views to different = VSPs.=20 We don’t need a routing protocol to handle emails, so neither do we.

From: Dwight, Timothy M (Tim)=20 [mailto:timothy.dwight@verizon.com]
Sent: Monday, February = 26, 2007=20 11:58 AM
To: speermint@ietf.org
Subject: RE: = [Speermint]=20 Multihop routing

Isn't any issue relating to telephone numbers, = an ENUM=20 issue?  
 
It does seem to me that [infrastructure] = ENUM, if it=20 does this successfully, is effectively a global LNP system.  Maybe = people=20 are questioning whether that will succeed?  While I can be as = skeptical as=20 the next guy, I'm struggling to understand how this has become a = speermint=20 issue.
 
tim
 

From: Andrew Newton = [mailto:andy@hxr.us]=20
Sent: Monday, February 26, 2007 9:53 AM
To: = Creighton,=20 Tom
Cc: Otmar Lendl; speermint@ietf.org
Subject: = Re:=20 [Speermint] Multihop routing


On Feb 26, 2007, at 9:51 AM, Creighton, Tom wrote:

I do not agree that TRIP is a viable option for the = countries=20 that

support number portability. =20 It would be the equivalent to trying to

aggregate your IP routes in BGP if you allowed your = customers to=20 keep

their IP addresses when they sign up for or cancel their=20 Internet

service.  = Simply put,=20 it will not scale.


That is an interesting observation.  But it begs the = question, how=20 will any multi-hop routing work with number portability then?

I also wonder if this is a theoretical problem?  While = I=20 understand the goal, it isn't a problem we experience today.  = That's not=20 to say that nobody does multi-hop routing today, but that it is = usually=20 achieved by VSPs in very entity-specific way and not in need of = inter-domain=20 coordination.

-andy
------_=_NextPart_001_01C75A87.13952D56-- --===============0668959148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0668959148==-- From speermint-bounces@ietf.org Tue Feb 27 11:09:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4tQ-0002Dl-Vb; Tue, 27 Feb 2007 11:09:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4tO-0002DV-It for speermint@ietf.org; Tue, 27 Feb 2007 11:09:30 -0500 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound1-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM4tJ-0008C9-0P for speermint@ietf.org; Tue, 27 Feb 2007 11:09:30 -0500 Received: from outbound1-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-fra-R.bigfish.com (Postfix) with ESMTP id 83EA28E3D2E; Tue, 27 Feb 2007 16:09:24 +0000 (UTC) Received: from mail44-fra-R.bigfish.com (unknown [10.4.252.3]) by outbound1-fra.bigfish.com (Postfix) with ESMTP id 78D82A78068; Tue, 27 Feb 2007 16:09:24 +0000 (UTC) Received: from mail44-fra (localhost.localdomain [127.0.0.1]) by mail44-fra-R.bigfish.com (Postfix) with ESMTP id 68A602800CE; Tue, 27 Feb 2007 16:09:24 +0000 (UTC) X-BigFish: V Received: by mail44-fra (MessageSwitch) id 1172592420606273_15163; Tue, 27 Feb 2007 16:07:00 +0000 (UCT) Received: from plss1667.corp.sprint.com (unknown [144.230.162.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail44-fra.bigfish.com (Postfix) with ESMTP id 30253200046; Tue, 27 Feb 2007 16:06:59 +0000 (UTC) Received: from pdawg05a.ad.sprint.com ([10.229.77.254]) by plss1667.corp.sprint.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1RG6oSF013171; Tue, 27 Feb 2007 10:06:54 -0600 (CST) Received: from PDAWB15C.ad.sprint.com ([144.226.76.138]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:06:52 -0600 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: [Speermint] Multihop routing Date: Tue, 27 Feb 2007 10:06:51 -0600 Message-ID: <92FFCF194CB9FF4CBA28EE5D5A89C1500BA73510@PDAWB15C.ad.sprint.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Multihop routing Thread-Index: AcdaaF4IMhJIDbySRCeyOka2MckUNwAEVsoAAAPNqTA= References: <45AEC6EF95942140888406588E1A6602F76C2F@PACDCEXCMB04.cable.comcast.com><977AF3D5-9F8D-46C7-9CDD-E052B90EFF8B@hxr.us><20070226164230.GE8571@nic.at><20070226215643.GA32057@nic.at><93ACE2DE-66FA-465E-9150-69F006B1037E@hxr.us><20070227112538.GB15230@nic.at> From: "Egbert, Brian G [CTO]" To: "Uzelac, Adam" , "Otmar Lendl" , X-OriginalArrivalTime: 27 Feb 2007 16:06:52.0994 (UTC) FILETIME=[4BAC2220:01C75A89] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I normally refrain but I find I must agree with this. Brian Brian.G.Egbert@sprint.com =20 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Tuesday, February 27, 2007 9:36 AM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Multihop routing Though ENUM is certainly out of scope, there needs to be an = acknowledgement that ENUM does, can and, as it's being argued in the = thread, should be a lively topic for SIP Peering in general. I don't = see any harm in delving into the topic on here. From a macro-level = point of view, ENUM needs to be acknowledged and understood in = conjunction to the SPEERMINT-specific charter items. As it pertains to = I-ENUM and peering, I believe the ultimate end for the most effective = SIP Peering model necessitates I-ENUM. It's another matter entirely if = the goal is achievable. A model with I-ENUM, DDDS, SIP policy, etc =3D = is really the only way to offer a well-balanced solution for those with = consumer, commercial and practical interests at heart. =20 -AU > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, February 27, 2007 6:26 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Multihop routing >=20 >=20 > Interestingly enough, Richard Shockey talks a lot about I-ENUM=20 > defining new "business relationships" and "carrier business rules or=20 > carrier to carrier business structures" in=20 > http://www1.ietf.org/mail-archive/web/enum/current/msg05529.html >=20 > You thus should not rely on my word. I recommend you contact our=20 > esteemed ENUM WG chair and cross-check your assumptions with him. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 28 17:14:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMX3h-00065b-AK; Wed, 28 Feb 2007 17:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMX3g-00065W-OI for speermint@ietf.org; Wed, 28 Feb 2007 17:14:00 -0500 Received: from unknown-141-roc.globalcrossing.com ([209.130.177.141] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMX3c-0007Dj-Hr for speermint@ietf.org; Wed, 28 Feb 2007 17:14:00 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 29608E8EDF for ; Wed, 28 Feb 2007 17:13:26 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 17:13:25 -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 Date: Wed, 28 Feb 2007 17:13:25 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VoIP Consolidated Use Case Draft Thread-Index: AcdbhaphOVqb/JfWQayN1r9g0cle5A== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 28 Feb 2007 22:13:25.0855 (UTC) FILETIME=[AADA26F0:01C75B85] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Speermint] VoIP Consolidated Use Case Draft X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Folks, I am not sure why the consolidated use case draft hasn't been posted yet. I believe that I met the deadline, but in light of that fact that it's not yet posted in the archives and to get it out there for review, I am posting here until it's official - http://voiploser.com/misc/draft-ietf-speermint-voip-consolidated-usecase s-00.txt=20 This is a collaborative work from a small gaggle of folks as you will tell from the document. This is work in progress and I plan on submitting a -01 version in the next couple of days. Work is fast and furious on this draft to get things ready for Prague. =20 Feedback is most welcome -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Feb 28 18:52:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZx-0002TS-HL; Wed, 28 Feb 2007 18:51:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYZ9-0001I8-Sj; Wed, 28 Feb 2007 18:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMYZ7-00088r-1K; Wed, 28 Feb 2007 18:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CE95C2AD3B; Wed, 28 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMYYc-00043y-IU; Wed, 28 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-consolidated-presence-im-usecases-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : Presence & IM Use Cases Author(s) : A. Houri, et al. Filename : draft-ietf-speermint-consolidated-presence-im-usecases-00.txt Pages : 13 Date : 2007-2-28 The document describes several use cases of peering between two or more service providers that provide real time collaboration services and presence and IM in particular. These service providers create a peering relationship between themselves thus enabling their users to collaborate with users on other communities. The target of the document is to help understanding the requirements for peering between domains with regard to real time services A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-consolidated-presence-im-usecases-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-28153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-consolidated-presence-im-usecases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-28153513.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart--