From dschwartz@xconnect.net Wed Apr 4 03:41:57 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4AE21F86AF for ; Wed, 4 Apr 2012 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.012 X-Spam-Level: ** X-Spam-Status: No, score=2.012 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DC_IMAGE_SPAM_HTML=0.001, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29Ap51pkzA9i for ; Wed, 4 Apr 2012 03:41:56 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id CA32321F8503 for ; Wed, 4 Apr 2012 03:41:53 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 4 Apr 2012 13:41:48 +0300 From: David Schwartz To: "drinks@ietf.org" Date: Wed, 4 Apr 2012 13:41:46 +0300 Thread-Topic: Following up on discussions in Paris Thread-Index: Ac0ST4lNE2GUntZlRrmCe33e/OEx2w== Message-ID: <0AE6CEDC-8317-4074-8F58-CAB5409F167A@xconnect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_0AE6CEDC831740748F58CAB5409F167Axconnectnet_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [drinks] Following up on discussions in Paris X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 10:41:57 -0000 --_004_0AE6CEDC831740748F58CAB5409F167Axconnectnet_ Content-Type: multipart/alternative; boundary="_000_0AE6CEDC831740748F58CAB5409F167Axconnectnet_" --_000_0AE6CEDC831740748F58CAB5409F167Axconnectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since no consensus was reached at the meetings due in part to many remote p= articipants having severe communication issues I would like to float my sug= gestions on the list in an attempt to reach consensus. The issues that were raised included: * comments about the name "route" (e.g. RteGrp and RteRec) not being accura= te as LUF involves finding a target and not a location and as such the curr= ent model is inaccurate * proposal to use the more standard term "SED" and rename RteGrp -> SedGrp,= RteGrpOffer -? SedGrpOffer, etc. * Comments about a missing abstraction layer clearly disambiguating the LUF= and LRF resolution types I am attaching an image highlighting my proposed changes. Specifically, I h= ave made the following changes. 1. Changed "Rte" to "Sed" 2. Added abstraction layer CLEARLY separating location from target as per R= FC 5486 3. Added additional RN type (for discussion - hence the dotted line) to dis= ambiguate location type RN responses and target type responses. For example= , assume the following portability URI sip:12121234567;rn=3D17185550000;npd= i@212.1.2.3;user=3Dphone, a "location" type RN record (i.e. "NAPTR") would = be used to have the domain portion of the URI specify the location of eithe= r the recipient or transit provider, and a "target" type RN record (i.e. "R= N") would be used to indicate the need to ignore the domain portion (e.g. i= n case where it specifies the donor provider). [cid:E2AF4459-1E84-4AC6-BC0A-927C94628E73@xconnect.co.il] :D --_000_0AE6CEDC831740748F58CAB5409F167Axconnectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since no consensus was reached at the meetings due i= n part to many remote participants having severe communication issues I wou= ld like to float my suggestions on the list in an attempt to reach consensu= s.

The issues that were raised included:
* comments about the name "route" (e.g. RteGrp and RteRec) not b= eing accurate as LUF involves finding a target and not a location and as su= ch the current model is inaccurate
* = proposal to use the more standard term "SED" and rename RteGrp -> SedGrp= , RteGrpOffer -? SedGrpOffer, etc.
* = Comments about a missing abstraction layer clearly disambiguating the LUF a= nd LRF resolution types

I am attaching an image highlighting my propo= sed changes. Specifically, I have made the following changes.

1. Chan= ged "Rte" to "Sed"
2. Added abstracti= on layer CLEARLY separating location from target as per RFC 5486
3. Added additional RN type (for discussion - h= ence the dotted line) to disambiguate location type RN responses and target= type responses. For example, assume the following portability URI sip:12121= 234567;rn=3D17185550000;npdi@212.1.2.3;user=3Dphone, a "location" type = RN record (i.e. "NAPTR") would be used to have the domain portion of the UR= I specify the location of either the recipient or transit provider, and a "= target" type RN record (i.e. "RN") would be used to indicate the need to ig= nore the domain portion (e.g. in case where it specifies the donor provider= ).

:D



= --_000_0AE6CEDC831740748F58CAB5409F167Axconnectnet_-- --_004_0AE6CEDC831740748F58CAB5409F167Axconnectnet_ Content-Type: image/png; name="PastedGraphic-1.png" Content-Description: PastedGraphic-1.png Content-Disposition: inline; filename="PastedGraphic-1.png"; size=89357; creation-date="Wed, 04 Apr 2012 13:41:47 GMT"; modification-date="Wed, 04 Apr 2012 13:41:47 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAGQCAYAAAB29rNUAAAgAElEQVR4nOydeZwdRbn3v9Vnn30m k5lJMtn3nYQACYEQDKuAgoCAiigquHHRq8JdXO9V79WrV+Sq1x1EX0EBF0T2JQkYkpCF7PsySSaT ZCaT2WfO1vX+0V3V1X1OAgmoV+lfPienT3d1dXVNPfV7nqeeqhJSSkKECBEiRIgQf1lYf+0ChAgR IkSIEG9GhAQcIkSIECFC/BUQEnCIECFChAjxV0D0VG8UQgh1+AaVJURx6EF6GQ7YhwgRIsTfDcTJ 9Oku6SrCtYzjkIzfeMgi3+YnJOQQIUKE+BvGayJgg3gFDvFG582bV5NMJqsikUi51dvbYUupyVca xyFeHUKIon8ESwjZk8lk89FoesWKFUcB2/1I9xsppf2XK2mIECFChHij8KoELIRQlq4FRGpra2Nz Z86cVlqSvKTWikwXMWtcys6vllJZv6+VfF/r8PNxsvtrUbw87o9XwcnwpEPItrRlTkYG2nPZg0ey +bWtra1r1q5d2wnk8JOxDK3hECFChPjbwgnHgA3yjQBWZWVl6ozZM85pKCn5xymJ2JypMRI5SSxN ZLpzQ5AXhcrId0r9km4KaZ4Xlnfh+CV7Da92vDQuTwlXAZBBT68I/OY4v4OnpHEki3Nz8FHBe9TT 9e0SaUvaiGY2Zu1eIeq+NHLkyF83NTX1AFk3uUnEIUKECBHibwTHJWAjyCqCY64mTjvttEmDU2X/ sSAVGXdNikTUckjMHACWQmDGZ+ljHx8KTcrOl5neyMyjZ4qSeUF+RtpX4d+C69L9L8i/xyNoqSnS y8NGGa/OdeOSImXnW/rezEmr8nOvSEcLkUDWlvENURG/1059PjZ+/LGmpqZH3YJkVQ5CCCt0R4cI ESLE3w5O5AcWOARtAfExY8ZUVpemrhgTj4y7NiUSMSH0oLCTWjjka94uhOOQFgbZaIJ2CUcRn0ua UgSd2MKxVoVLsno0Wp23jPNC51OUgJUj3QpcN/OUwm9LqucGM3XPO/8c3vUrE1bRcghXKZFKkZDB /KRB+iCkJC5gWszi2hIqK8tK/gFIATH3o94oRIgQIUL8DaFoxx0IuooC0VgsVlUZj11weVKIiBAq DFfdYHCN+7/lJ2jzmvsM/VGWrxAukXECf2qQoRWpFsRmG6+gCFrdoPIwydW01H2vb1jeQetbSp1W Z+lm4iQvYF9dNvWe+j83rUQRsbrkkHVcwISIiAxIUV9WVlYBxHH+NpqERcEDQ4QIESLE/1UczwUt 8FzPUSABlCej0enjo8SVq9kcqpWm+xg0OXmOW+e69F1WOQhNRFJIlwMN3UAxskmCBQyt8jBKFbSk ixz6szCo36cFqIJL4/mGu1qAcJUCqV3Q/iFf4b68jpUSLtma+aCcznh1JyVCOo5uyxLYyEhPT08C xwpW0dCW+31C3SVEiJOFEGI4UGmcapFSHn2deU6QUm4/zrWIlDIvhBgEdEspM6/zWaOklHtP9KzX k3+IEK8Hr+aCjuAQcFxKmZSSZMrybFm/F9ewhoVA4hG0ckxLdawsX/Wx0FatKMgZj3yDpStKpAFL 1We5BizeYDpfxkGXc/CFBU4gl5/vlFNah1QJgbCEN3lXW+PCVzeO0iFc4vX7C5RrXyDIS2dIwPhE 8JSlECHeaNwBfAp4H/B+4BYhROp15vmNE1y7yP2eBlS/zucA/OsJPEMXHed8iBB/ERzPAjajn2NA NJfLJfRV4SeIAoL0XQ+4f81j9/9MPs/2jm6ODqQpj8WYMqiaZDQSIF0/GUopOZbO0JfN0VheSs62 2d3ZzaG+AUpjUcZVVVCZiBeUSROg7VCkDbQPpDnc20fMsrRXvTweY2hZCT7rt4DxA9a2ORPIfE/b VVA8RvWCt1zr2bGMFW1LZ4xYGdxSuh4HFS9OCkjjBGEpAs5SWMAQIV4v3gO8F3gBpy9YAzwJrBFC TAMGAZ1SyleEEFHgLJx+ZbeUcr8QohqY4ea1BugFrnBnWEyRUm4EcPNqBh4TQswADgD97rU5QCnQ K6Vc5VrHde4nBywzp+EZz+wErgduFULUAlPcJBtxRF89ayNwplvutJRy1RtXfSFCHB8nckFbeJ17 3LbtGGBENXvuZTVmqcxEPTTqEq7nFzVsYtf9nMnbvNx6lM8uX8fhvn5KolH+9YwZXDlmuJOnFXBF uwfpfJ7F+w+xrKWVr8w/nSUHDvH99VtZ39ZObSrJB6ZN4IaJYylLxJxbgtNkXUs+nc3x3L6D/GDD NkpjTnUkIxHmD63j9llTvef6+NcXpYX2NwvXpaxsWCNwWgU6O6mlrkdpS6OOPP4UgfJq7nYWOUm4 nwGcTjFDYWhZiBBvBHI4RFiH43H5E1AlhBgB/BPQCLQLIT4ODAH+203/NPAVHKv5bW5evwR+5B5b wPeABa6F+j3gkzht+t3AeuBFIUQ98G9ACdAnhLgVOBu4ESgDhgILgEOAil9Rz9zkpgF4O44yYQGP A08Zz/oS8FW33NVCiEuklN2vv+pChDgxXo2A1RhwVBGwhksQQpGOiuJVQ6Qot7TwEYtr8iHdiKWO bIavr9nM0YE0X59/Ovdv38M31mzi0lGN5Ow8q4+0E7EEoyrKaKwopSeTY11bO92ZLIsPHOLJpmY+ NnMyNz/1AuOrK/jCvFmsPNTKjzZs44z6OibUVLCx7RilsRilsSjpfJ50Ps+xgQyl0SgTqitIRqOU xWI8u+8gyWiEd4wbybF0hs3tHUyuqaI7k2X7sU6m1FSy8WgHScuiK5NlVHkZjeUl9KSzrG496pSz vIzGslKQthOUpXnUQi145Ri1UpO6cs0LpDFGLLxpS5rY9e0J9++iXM8RtBdbiHBRjhBvIAaA24Bl wGDgOhyC+wLQDXwax8p8G1AB/AHHWr5ACFHmXh+G0z57gZ8aeU92vwUwXUq5WghxCPhX4HPAKuDz wI+klL8VQrwTuBXoAaSUcqEQ4rPA5cCP3bxKgDtxlIFS4Bb3/Ejgsziy8oSU8j+MZ9UBTwBLcZSG 4cDm11dtIUK8OgoIOLDJgurYo1JKJ62UYFm+8UmV2GEMZfWaQVfK4jOI2PK8tum8zczaasrjMW6Z NoFtHV305fP8btc+vrB8LaMqyjizoZY7Tp/OE03N/NOLqxleXsqxgTSDS5K0p9MA/PjCBYyqLGXu kDqerG4mbefZ1dHNNX94ltn1g3jLiKG8cOAQB3p6yeYlPdksd58/j7eNG8Wchlou/c2TlMdj3LVw Hr/esZtPL32Z31x+Pk81NfMfK9dzz0XncN1jizmjvpa9Xd2cO7Sez501k9/sbOILK15hVHkZZ9bX 8oWzZlARjztWrJCGcSxAT9V12FloF7et/gBGdLlL4Kay41RbDG98vsiAdYgQbxjKgO8DL+K0uWuA Wpwx2mE4bbEUWAs8A9wFXOD+bgBWuQqhFEJ0uOnBafU599iMX4jidzGdA3zcPV7vPn8zjvUN8Csc UlaoAja4c+K7hRADOLJR5t7TB7QFnlUPzAFOB05z04QI8WfHqwVhKQvYUgQsXYJQI5ZCSicC2LLc +a0e6Xo84vKD4UJWh9WJOJ86bTJ7Onu440+r+fzydWTzkubuPm5bvJyFjQ28a+JYfrVtL0/tO8in l77MpaMa+eEF88lLSc6WZPI2UctiVGUZvdk8v9+1j95sjm3tnfTlcxxLpxlfXcn5w4expb2DmGVx 76ULqCtJ8snFy43XdT6JaIRpg6pZ39bO5vZOfr5lJ2cOqaU/n6cnk+W6CaP5/JmzuH/bHl462Mpt S1awcFgD75o4ml/t2MPa1nbDYhXaHa2c9tph4LrrXae04Skw3QhuYJZyWTsuaJN8I4QEHOLPhxyw RUrZLaXsAH6CQ7xPuMffx3Hn7gXOBb4JfAL4MI6FPEcIMV8IcZ7724xqlu75C/HIOA/MdL8BHgLe 6Y4DXwUsdq+pRWiyRlqAY8B0IcR5Qoh5eC7ojwP/DtyN40KPGc96K/As8C0ckp90KhUVIsTJ4kQu aJMNLCmlhT5p/K8sYHflJmWkmWPA3jip8IKg3DxsBLFIhK+fczqDUgke2L6XL7+8nm+XJMnZkm3H uujN5mgsL6EjnSViCd43dTwjK8pYNGIoKw+1EY1EyNh5Nrd3MLKijO5Mli8vX8u02hp+eNG5DEom +dp5Z9LS00dEWLxt3EhGVVZw6egR/GTDVi+0yUUkIhhSWkptMsl3121l9ZGj/NeCszg2MEBJLMql oxpp7uklJ2329/Q65ezopDeXo7GslK5M1gv6UitcCcA2x7/xLGAnhc/ylYZ72hxFV0VUf5cif68Q Id5IPIvjhlbYgUNQPwUeA2YBY3EiigdwCHg98Hsp5WEhxDeBf8EhwjtwXD1L3O9v4ozvSvc5APfj RFy/hDMm+2XgdzjBXeo573Cv4T5ziyqclLJPCPEdN98W91kSJ3DsH3GUgNU4Vrt61n1uWd4CHAEu xVEwQoT4s+JEa0GbBOzr4JVrWdOHCsgyg5TUAKh0w4v0Sk+YK1ZwdGCAjy9ZQVksxn+cfTojysso jUVJRiNMHVTFBSOGcEb9YJ7Zd5DZdTXUppJ8e+0mrp80lj/u2c+YygoqEjFqU0luf/4l7jxjJkPL S6gvTVESi9KXyyGR9GRyDOQdN+9D2/cytqqCR3Y1MaW2mr5clv68t4pjXyZPZTLOR0+bwkef/ROz 6gYxtDRFW38/vdkcD+7YS38uR3UiwZSaaqecw4dyRv0gnt3Xwln1tb6K1PFbxqwlNQbsrRstUNHd ZkCXCsYKDOsq8g2JN8SfFVLK6wO/HzB+LhRCxI25uquFEG/BGbLKuOm/KYS4yz1WlupC9/ubQoi7 zLm4Usp/LhLHEHzOA0b6Q8C9gTL+uxDiq4E5vpcXmfern+WWW7rHoUyF+IvghJsx4HXwRoStfwEO lUoEfggvuS+1w71Sp0tEIlwzbiTfWLOZK/7wLDHLYubgaroyORYNH8rda7cgxBaGlZVw1pDBXDpq OP+7bgtP7m0maglyts3qw228c+IY/nPlOq5+5BlSsQjzhtZzqLeP5S1HAMFju/czkM+Tl5KOgTSf e3E1Hek0V08YzR927acrk8USgpy0eXp/M/OG1DF36GDK4zGumzialYfayNp5erJZfrBhK9vaO5le W83erh4WDR/C3a9sIWIJTqutYVAq6RmtQriBWIpwAxXm+PF1FLTzHViMw6u9V/lzhWQc4vgIxHe8 UcgJ36o5Rc+5U+AL0oHjhi44X4QEiz3nRCiW76s9S6jj10nCWlDDgMgQJ8KrEXARODThC76ypZ7W o6xfqVa50lOScNMbZGxLerI5DvT0cf2E0b7pOYsPtABw/cTR+s6lBw475yaN8ZXouX0HQQiunzQW Kb086kpS7Oro4sJRw3h230EiQlAej3HrzMmMr67kno3b2Nrewdb2DgBOb3As16X7DzGqooxnmw4y qqKMK8eO4rc7mxhVWUZDSYpH3n4hn1u2mmxesrjZK2fMspgxqIqInjrlze0Fd5UvwwL2piWp2Uve FCaHs6VH3uggrFdDgb86xJsXxrKy4J+q9ucg4zc7TIEHh/CleT4k5BAmihHwiQVSLUEpJWA5xCvM abKGBWyMBxdrdcKdXvTjC+br+8xALfU837e6pNaDtoLFFYE38BSDjoE0d63eyOiqCuY3NjC/sQEf Xxlk19LTx9NNzbx/2kTG1VTxqTMq2Hmsi7lD6qhJJvnfRfO9gVolX4alW1Aeb8Nk93JgWpIxccsM 4MJQZIyMzTcMV8AKUYDAeu4WIOrr62OTJ08eYllWXVyIHgYG0uY9tm0Ly7JCgjhFZIWQKcuSA7ad 70yn+wYGBtIbNmzow9su1Hb/LuH+3SGAVw/CKtCShbEBAcqdrMd0DevW/c8hXxHIBYpubhAk3+MV TfGeEL7x5ELbz7REBVXJJF+cP8d4hDDIziiXhCFlJTx+zaXaKrWEYEJNBQ9cvsibNqTKbwfLXFy2 TNe9cKcnBbct9Jbt9MxjNUQcSmyI1wKDfPUSpTNnzqwdPWzY3OpU6q2pZGJ+icX2bD7fdsKMTLyK mnfyWmDwjuBOmlbg/PGeELx+ajtyHveuk8xOSCHzgv6O/v6W9v70oaGDB6998rnntro55fGIOLSG Q7x2F7Q7/SVAnBIpLUM2HPevb/xX86MEaXkWnZOpl5+e11TE4tUwiF4zmWEt6mk7+InZvN//Vujo KHfOrmexmre4LKjz9ILLfKxqRDH73sV9TycmTQVVKfJ3rdyA1aynLOlXDGU1xKujCPlaY8eOrR03 YsR7J9RWf3JKdWWqIZVMWcKa2DaQLnQ84f3QzbjwUiFUgGHgpuP6uYuI4gmvG6d8SU05lYWnC34f T4yOc77YaTOvwudIcjZ0ptP5A7396eaunmULFy783OLFizfjTJlSlB6ScIiTHwP28ZKx7JWedqRJ Rvi5yiUatRmDkYmTqWU+IWDleomLoND6Pr4busi9+pEGWapL6rxe0koGbjV6G70XkY+RjWcpd7Or jmjXsu3ys7vWs5T+fkzvihTML0QIP4qQb7ShoaFk+vjxi4ZVVXz56tHDmVBZ7qZ17/Fu9jmggsd+ cfR0cSOe8oSkKUQxmTDSBBTuoP5d4KgqmpOZ1htWCg70+IlTGnKuU3heOz0LoTjxq1kM5v7eEom0 ZaQ9ky15tKn57Bx8afr06bdv2LChBW/N9hyeazrEmxQn7TkS4K1THDBgnQTufkBC7XjkJFQLTxgS iRYj4csdnbn+CqjpwmizPskPkLv5sfAKK4LHHKcMaBe03w9sELdW9WXh7+MpAe70IhUN7hXZKZPD +cKohVBGQ7wmqJaulieNNtbV1ddVVXxi0dD6/ITKcrfZe21Rao+W9IY9zNwcndAVH9X+HZmQxlaa Ek9UnFvdPgB//2DuA25+1OMK4ObpiaspFwFpVSvGqbK6/YZz6CnAftH3OjBpyJkw8jMddV4Ct76U zKrF3l3qtiyLmmSct49qTI2tLJsxdOjQa/F2MFNKko66DvHmxCkE8ARaohI4oYjEa8aOrLqCIIUv vd6d4HjWqSklpqtXqD4GfOKn0wbKqZMEyTdg0Zrk6Xu+J8gOqQbVfWmkB59LXL2nmad7SSJQXn0f VHbSLLrQRQgR4lWgmk0MSGSgNB6Jjp1ZUxlRJKmIQ2ASh9pI0yQ0L0ctLcJLZRKnFk3zZim190tI RdrB4noeH4QTU+mLqwwwnxCyQDR9Sr10iNHbXcwtq9YVPJLW+rSreHhGg+ONMp1vSu/wug6vvsDr 3pTCIt0ZDCXRiDi3oW5QKh4/F0jibu+KpyyFYv0mxsm7oDX/qDmrDpxN4/1WL9Jd9Uk1aPc+9Lco kjE+gXNPuNq4yULGc0w9oqA5mycChH/Cph/sKYT/lE/yil0w1nYGzzxw30NtTygL7jeyUX2j20nJ gnoJEcKB4X62cLcQBWKZTCaVlXaqMpHwXMaAJj4lxyooEE+uhXvdOasbo49ssIQSdYMLBbadp623 n52HW5FCMqKmmpGDqo0FZYQqt5cXkM3l2d12lOGDqtnVepSYsBACbOkEQo6pG0Q0EjFdbkZhvCmI +i3NzU1w+inbeJ5+O+nVBxLDoeXGbpgubXf4SE95NNNbRnoJUSFoLEtFiVjjcbYRVW7nvPEd4k2K kyZgHQUtlftKXylKfp5gGuqk8kn5NNggORrp9WWVRhZeN55ZYAkX+xnkTN8gjyGd0riuFQuVpAh5 mh2DhMIHOec849fpvaS2RIqVTbhrbhch6hAhPFjGJwYkcrlcwpZEIlrvDQiAa6WKgJx4eqP0LFJF YoZcmHGL+l4kPek0P1iyjF+uXEs8EuHc8aP51EXnMbau1i812ovrZNLW08udDz/GV666hH984BGi EYuoZZHN56lMpfjhjVdTWZIyjHNTVoV36FrbTqCT/8WE+15mQYKKQDAmxMje2b9b3SONa1IZIl4+ lhAkIhFh2zKJQ8Bq7DfvHlvuYlyhcL8JcfIuaEMIBdLv2pFew1fSKdxjc3xFk5koQk5mwzeVZWGk 8ZG58dMy83QvFAzeGO9h+rAK/Frm+5rnzPTqPYJWdcCPbL63EmgpfK+vxua0C8zQURAYm1yECFEU phREcQg4ls/nEzqFtuSkIVLukVYq/XqjHr81iNs39qvHQtE32MD+Y53c/dyL3LLgLD598Xm8sv8g v1q1jlw+z84jbSzZtpPVe/eTzefJ5/PsOtLKC9t2seFgC6v27iebtxlWXUlfOsMzm3cAkIhGeOVA CxLIZHOs3rufnnSGVU0HWH/gIEu372Zzy2Ekkkwuzyv7D7Jk2y42HzyE94KuIlukS/DevpikGUGl vtTe+ztE7JobBp8bKkISZytRHSRH6IZ+U+MUVsJy4Aih5fGmz/2spVNbj/4ABlwisgpVAM/3hU/F 1tkGrG4zvcTXUfiJ1JwTrJ4ffKgpfEWs22D59VSkImbA8axZ95zn0hLoEGrh7QdcYNeH7Bvi1WEG YFlAIp/Px/VVw9LV1pzb9qVQcb8qcEqp1dIVUeldFYH8TIeUlEjbZiCbIxWLMamhjmQsxqcvXkhl KsmBY5184ZGn2HGkFSR8+apLmd7YwOd+/yQ7DrfRWF0JQG1ZKT993ztZu6+ZK797Lz++6Z209vTy rh/+gmX//HFaOrq58Sf38/BHb+K9P7mfxqpKOvr7qUyl+P6N17D/6DE+/dCjRC2LskSc/3nXO5hQ P1i/u15j3WfoSm0hB4lWv7+ZPmBhS92vuTXln14ocMg3jjdEkCMk3zc1TtoC9uhBGEeesGr1WYBe bEITp6EWKkKUwpOCAvex9Ew/I4DJOzA1WcNFDIWWrwh+LMPqtfzmpvkcM7RTXQiSoTm4pi3341jS RvGc78JxKzO9VHkGqyZEiOJQDS8ORGzb9ghYm7bSGNLQIVWYbmhlKVuBbP0BTp5tZ6qtkYhFY00V MxqH8NXHnuWfHv4jv39lI5lcnsXbd/HMlu38w1vOoTyV4P33PMCqPftZvG0X//OuK1k0ebxRAknO trVSWlOaAuCpTdtZ1XSA8mSSZCzGgfZOTh/ZyLevv5Ith47w3ef/xFcff4723j4+snAeq/c1c9fT S3W+5lCO6jJ0Pyb9SnBQ5nzdgYqsFl6+3j0+v4BaRyGOQ7xRwm1EQ3DKY8A4mqI2QJXm6M1Z9dwx AUhJTkr29/QyYDvxBxFLUF9SQmVCBQeaD1T3oS1PW0L7wAAdmSzjqisNi9lD3rZp7u5lT2cPEUsw vKKMkZUVZHM2uzu6GFtTSVSo1QMkvdks29uPMbGmip3HukhGLaQNNjYxy2JcVaUuv97lSWm4viUp vXJ6x+pdXAE3XIDSJ/TKkpbO+toCZ7zJ0E9ChHgVCLzOPYZSsrX1K32yqWRX6c7Ca5harrSMGzay qeua7VLtF56KRrjjkoWMr6tlw4FDfOz+3/Do+i3c9pb59KQzPLJuEwKoKy9j08HDxCMRZo0YRmki zn8+/px6uGFtSypTSd46fTJ3P/si1SUp3jd/DpaA8mSCm+bPoSyRoKGijG0tR9jXfoy+TIY/rNvM 7BHDSMajSvwCnqhg7QlDfA3TPjBE6+jcInjamz5oF+aMNw1JL5JSWIMh3kw4ZRe0Mk6D3KCNSKHt Nz9ZCejKZPnKy+vZ19NDVSKBLSUXjxzGeyePIxFz95n3uZP93xk7x/KWIyzef5BvnH+2Lo8S2Lxt s7W9g2+vWs+jO/ZSnohx/shGPn3WLErjMe58fhn3XL6I6lQSANuGPZ1dfOb5l7j7gnP4yFNLGJR0 rgnhbOrww4sWGBzvY1W/kqCjmgW+dewMQhZGGKlAGp56I7Jc4ERZqqcV6yxChPBg+ndU5y5s244B ethDuPEFam1yoSKs1AptCD3bzr3NI1u9kI4n0kGHkaMg2+xuO8bHf/lbPnvZhZTEY0xuqKcvk2Fc XS0NFWW8d94c9rS1E7Espgyt54dLl/Po+i1saj7kxEJYAZePFJQnktxw1izufvZFhlSW87MP3ED3 wADdA2l+tHQFc0YNZ2/bMW46+wye2bKDrv4Bbp5/Jiv27uOiKRN01LJ0lWbT6VVMvor91iSu0xsj wIbiXRAW4ilE6u9j7ukdEvCbFCdPwOacPKMFS4kWYhSRGFHSeuxIWPTn8jy7v4XyeJQZtTVsO9bJ l5a/wqWjhjMYwdq2o2Rsm6pEgmm1NWTtPGuPOOfKE3GmDKqhNBalIh5HImnvz7Cx7ShRy2J0ZQXJ aJSvL1/LioOH+czc2VgCfrB2E92ZLF9eOJflBw+x7kgblhDUppJMGlRNIhJhSGkpiUiE+pIS1rce 5XBvH++cNJa4ZbGq5QhzGgaTydtsaDvK5JoqtrZ3ELMEHQNpapMJJldXkbXzbDraQXcmQ20yyZSa Sq/ezLFiaXseQbcrEGoMWOoaMxxZMhwHDvFqCJKw6uS9qy5zOGIrDJZxrVsRIA/Tk2N8m+TrJRY6 vWXB1KENfOyXvwGgprSE/7jqUmrKSqhMpbjppw9QVZLizksWYkub6pIUH/rZgwAMLi9lx+FWjnR1 s6e1ndJEnB1H2hCWoKashNJEnFG1NfRlMzQf6yKTz/Hijj088somastKmTOykZE1Vdx0z694909+ yeCyUi6YPJ50Nk8iFvHeU7p9lDsvyedsU94nNVZsVoEwHWH+MWNPNXctYT+NR4yPoLAGQ7zJcOoW MGaj9FzQgN8ClgBesJbSEMtiUS4aOYzLRzdyet0gXmltx7IEG9uPcdMTS6lKxolZFvdcsoCW3gHe 9cfnGFZWSnk8xk8vXUhr3wDN3b30ZnL8ZN1mvv/KZgaXpLhgVCPvnzGZR3bs4d8WnMVtZ8ygL5cn Fonw9ZfWkJeSrnSGry5bTcdAmupkgh9dej4Z2+bowABjqiq47/JF/O/ajXx3zUZ+ePEC1h9p512P Psuyd72dlt4+bnxsMQ+/bRE3PraYxrISOutcv6sAACAASURBVNIZqhJxfnDBfPZ19fDppSud4I9Y lO+efxYTqiv96rQee7Nda6SIHLrEbNraobiGeA0QgY/hgjZTGQThu2a4VdV5gX+ajlDEEly4w+kH +tJZFm/dRXkiwZWnTXUfJ3hi0zYAZo8YxqzhQxFCsHLPflbu2c+sEcM4bcQwTf4/f2m1LtE540fz 61XrmDOqkWQ0Rkk8xicvXMAzm3ZwsKOLweVl3H/ru3lh+x6Wbt/Nj19YgQSumjVNW72/XbORcXW1 1MXK9Wsoi9Vb1t3o0Yz5w+Z5ZTkD3nKyGERrzBtWunVAbzbJNyThNzlOnoD1umyeAm22ItNl5SyC 5bRuFS2JJRT18PCOJlYdbqM3m0NK6BhIs7W9k5pUgvdOHs+//mkVv9+5j0zeJpO3+dCMyTy2ex87 j3Wy6Wg7Lx08TEtPL19f8QrfWjSfhrJSfrxuMwO5HKlolEWjGgFBwrI4c2gdzvQEm6hlcXrDYN4+ YTRXPfQ4927YysWjh7O5rd1xCktJOueMTwsENUlnJsdTTQdI53KUx6MkI1EOdPfy9rEjePvYEVz7 6HN855XNbGw7RvtAmi/OPY3bl6zkv9ds5vtvmYdPDIVA2nrxaF1zzvC6o5rr7Ql9QV2hCRzi1ODa t6ioZinVilIeseqJB8YdmO0QI712VZvDKQ5SsRiXTZ/MOeNH6/uLuGTdH+ZzjKsBWrJc1/HXn3ie S6ZN5PKZU2ju6ORQZxfrDhykLJFg4aSxTB1ar+/R4RlALBKhMpXUzzEDlL3RMW1OeFHgrkwWm6Yr fMqK503Qc4Ix+kMHEd/tId70OIWVsJTLRXrHhgvav/+3clUZbc3QIN8/ZRx3zpnOxvYOLvzNkzzZ 1ExZLErHQIb7tjhz/0piUWYMrqQiHuNH67fQm83Rl8uTiESwpWQgnycVi3Lh6OGUxqKUx2OkYk7A xeKmZsbXVDKQy7Oq5QgCQSJqURaPceO0SVTE41Ql4mxua+fi0cNVAfF8dM6rVCbjvHXMCO5evZHq ZIL3TZ3oBH/EY9w0dQLlsSj1JSm2tneyr7uXvlyeR3bvZ3bdIJLRiCuJfrIl2O8UcUEjbW2B6MKE CHEK0PKJK8PBaXJC6vFfPRrsmbYoEtVxCZbf8lObhggk0YjFuPpafR4MS1plqRu29GvyQQTO/erD N+rjUbU1jBpUw68/PEq/yMhB1Z7Vqaz1AHfqulAuaPWO0kwTuEkFqhWcd8fWpX8v78JnFnNzhXiz 4+Q3YzD9U2ZgkTA1QkO4XXM4uBCHLSXbOjp55sBB/nTwMPUlKcpiUe7ftpvT62u5fdZUJNCXzXKo t4+LRzXywekTaerq5rHd+7AQxCMWVckEg5JJfr1lJ/dv2cknnnmRhBXh3Mah/OdLa3hsVxO/276H zy9ZwZlD64kA3eks31uznhcONNPa38/bx48u6BgsQ2koj8W4YfJYVrYcYX3rUa6bNAaA7kyWH23Y ytLmQ+zt6uHS0Y1MrK5kck0lN08dz7lD67l+wmi/Ku7Wi0AtxOF1ZJ4F7NWhxLs9MJ4UIoSJE7s0 hfa4el4shNb1fJOQlGUshH90RAaOpfdA6U5rGshmWbX3gF5Upi+dYfPBQ/RlMgggm8+z7+gxOvsG vIe5hBh8Ewmks7lXeWuJNyBtOtLRCkMmlyOby7O15Qj9mQy6Y1IVIgvjK1T51ZYp+qUDtSvAJV9p 1Kt3v7c2wonf4lVThPi7xCmvhKVdU+BYtdJza/ncSK6Ee9sQSpIRizPrB9Pc08d/rdrI43ub+ciM Sbx70lhunTGJAz29fH/9VuYOGYwlLMZWlrPp6DF+sWUnF48azu2nT2NcdQXzhzVQk0jwsdlTeXjb bn63fTcfP306jRVl3HXBOZw1tI7/XrGOn67bzGXjRvHzt11AIhLh9IbBbGxt5wdrNrFo5HCuGD+K YwNuhyAFUctibFUFc4fWg4SIZVGTSFAaizK2qkJHSGfsPC8dPMIP1m1l0Yih3DxlPN9aeBa2lHxt 1QY2tXcwvqrc6w3cukIJq6rBgIz6XYCqDsOlKEOcNLxG5OcH/9CR9BQ9fRE1V9j7rVyzOkJZePcJ IGvbrNizjzsffhTbtklnsjy3bScf/X+/4ZnNO5BAV/8A33hqCSt2Nzl3+gjUfD70ZzI8uXGbn4SD KkbBEnFCl8uWko6+fp7atJ3udJofLn2Jxzdu0xnoOQaGoiHN/6Urn4YCrRccMoqqosu94Ta3vtwp h0X0ZsO/FpLvmxmnvh+wmi9nXFMh/kLvdeu35lwJZlBJkp9ddA667Vmg2uJ1E8Zw7YTRWJalMgUE i6+7gry0iViOS3diTTXXTBoHwIdmTubmGZMAQSTizO1tKCvhwasuIS8leSmJR5zhlyFlpSx+z1UA 2NLGQtDeP8AvN+2ksbwMS0hSUYvrJo3lukljARjI5nip5TAlsRj/fOZp6m0ZnErym7ddQH1JElUb o2NRFl/7Vmzb9tbQ1QLsudukUrn1yvCGC9pYLV7pM9KwlkOEeA2wwHN9Fqxjo4KP3JOW2bbcRudZ x2BSrVoKwK81Ctp7+/ne88t4x+wZCCE41t/P1x5/juW799GXyXLFzMn0ZnI8tmErVSUpErEopYkE MxuHgpBsP9xGW08v8WiEacMaWLl3Px+899fc+4EbWDhxDBubD1GaiFORSlKRjPPKvoNYwmJIRQXj GgaRzeXZfqiVoz19lCWTjK2t4aHV6/niI0/z+O0f5OJpk7j15w/x1mmTSMSiznR7VXzpKRJ6TTAB tvRc727FFYRk+NaEdissuCa0WVMn8TcM8XeOU1uIw21q3hgwzm+XYNFfrtYshdcDOKeV74aAOgs4 ARdaXZdeuohaOCMwrxghiKh8fFkKIsKxYA3VQT/NwgIpGcjmOTrQzyfmzEAX3pgY2J3J8MjOJi4Z 1cgFo4YBkkREMG9oPTHL1YhdV5Ya67WEBdiF2rkiVncJyqJR0JbH1847mXp5iBAnDy215gIcyu0s vSao9WW1ypOncbsGniOXppgJQNo27b29LN+9j++86x0AtPX0sarpALNHDuNgRxfNHV1ELUFpPM6v Xn6FxzZspTed5jvvvorx9YO57Ze/pb2nj2gkwpffcQmPb9hKR18/33pqCcOqK7jmuz9j9shGrjht CololC/87klqy0sZO3gQP77pWnYcaeOTDzxC90CavG3zhSsu5AdLl9OTTvP7dZt4z1mzsYRg2+FW ZjQOcYnSrR/TQWVUmraA9SI6+OwJL6mSUa/vUq75EyAk4zc5Ts0FbbpTgwKK9LjIueA12kAwlt/v ZcCXVnofc+sVlamyLrWbVz3cuM83/mpcl87OYEMrSnj0msu4ZtJY4160eAwuSfGrKxbx00vPcy0F wZDSUn59+SIGpZJGeiXRgRcL+v7AXcQ+6D5Dv0/BfsBeTYYIcfLQIqEOXLtWSMcbI7225gucMg9c uTT9purblpL23j4ilmBQaYq+TIbF23ZRW1bKf119Ob3pDA+t3gBAXtrUV5Rzz/vfSXVJCR/7xW85 0tXNtkOtfGDBWcwaMZQtBw/zwQVnUVNawhfffhEDmSzH+voZX1/LuRNG8+yWHVw0bSLXn3kaS7fv ZndbO/ctW01bTy/33Hw9wwdVs3zPPv71rYuoTCX5yIK5RC2L8mSC5bubcKTJrQNDXINueaeOvGo0 XdB+/7HzSy1HqVa8CxHiRDjFtaClJlzddqUXRCSMFqyauTMWYqwMFbSIzbaqNG3fQx01PZvLs+1o Bzlpu1OXBljefJgX9h1kZ3uHq3EG1FmJs7Sj8du2JW19/Ww7esz5LSVH+/s40N1T+MYS/GNNslBK zecFnfPm8jnK0lB7ApsVEKwDlaUM9wMO8frgBRU50C1VCtdD5dlwSom2UW1OS7AzrmnOhQ08Q313 9A3wgyUvEbUsntq8nWjE4pcr1pDJ20Qsi7fNnMLIQdVcMGU8mXyO0niCuvIy7lu2iic3bkMIQXki QdSy9AYNg8pK+do1l1FXXk5lKsnK3fv4/dpNCCHI5vNsP9zKuLpaJtbV8pUrL+F9Z8+hvqIcSwhq SksKxm69fkz4RFZ6b4umWR3d7K0V7e+2pM5PBhWYECGOg1OPglZ8YarJRVqcHhPBl9hvaToZ40lA UHMULgFK2vr7uXPJCjr6MxztH+Dejdt5zx+f49Ynl3Ln4uW8eMDdeszvw/W+3MN0LscTe/Zxx+Ll NHd3M5DN8NTuA3xnzSaz8EXKJwPXAoqCj5CNdw1cl0IijUE4U7B9+biDbUJSpF5ChHht8LYhNAnF tNICKzopmTUsZsfJZHrA1FCK8zsWcbqTTM6mpbOLfe0dvGP2dKpKUlx7+kwOdnZxoL2DiBA8tHo9 z23ZybKde5k1YhjtfX2Mrq3hY+efTXVpCb9ZvQG1GcNLO5s8sRLQ2dfP79du4kMLzuK9Z5+OlJKI EJw7fjTLdu3l0Q1buO3+3/HIK5uJWBYD2RzL9+xDIsnm89SUluB54Ly12d1Xch6jFZbA5g3G62t3 vb8j9HZakoQsHOKEOKUgLJ/7SbtXHQtVuhsVeG4a97x7t54XLATZvM32jnbaBjLEIxaz6gYRtSya uns50N1LaSzGzLpBCAFNXT0c7O2jP2ez6nArxwbSLG1u4UvLVvOeKeM5o6GO767dyCef/RPLb7yK Xce6Sdt5+rI5ZtQNYmPrUZLRKF2ZLKMqyqlMxNnb2c3z+5r53ppN3HnWaWw/1sFju/bx7+fMYXt7 B219A5TEokytrQFbsqGtnbgl6MvlGFFeSnN3HwCz62qwcMp4oKeX0miEmbU1xMxAMtuw/nU9qL2T nY7R285MIN3wEDVEHFJviNcFTawe2WimVcfgWYLFiEPgzQN2GdrcCzciHBfvCzt3s/5AC5dOn8TX r76MSMTiUGc3B451sP9YJ2eNGcnmlsPc9cwL1JaV8s3rrgCgvbePe15cxYiaKm45by6l8TizRwzj N2s28IW3X8TcMSNAQnkyySXTJ3H/yrUIBGeOHgEIrp0zk8c2bOWup5dSX1nOrQvn0trdq9ea/uSF C+jsH2BcXa3PR+XfNdCD2k/B4Vfh1qGXWLo3FzjrXI9XIJQkRIgCnHwQlj5SDc9d6U74r6spSS61 oDVsJe+2TUtvL7ctWUn7QJqoZfE/C+fSUJri88vWsKOjC4nky2fPYfrgaj73p9Xs6OiisbwUgI50 mh+u28LcIXXc/Zaz6c7mmDq4mj/sbKK9P81nX1jJvq5uSmJR7rpgPtf9/hnOGDKYvZ3dnDt8CP98 1mkgYSCX59dbd3HdpLFUJZwVrw739nHbM8vozmTI2ZIvzJvN2Kpyrn/0WWbVDWJD2zEuHjmMLe0d 7DjWxU8vOoexlRV8/qW1Trml5CvzZnHRyGGqMvxeaekSrPTqUQ0fO3Fc0ttoya3L0PoN8bpgeKH8 Y5rqP2NxSWHcYEb/Gop1kKMHcjm2Hj7CpIZ6vvjIk4wdXMsDt7xHXx9SWcEjt92MAG5wZxJIFazk 5rn4jo+Ss3NYQmBZzqyFxz75QbcvsXjgwzcCkpqyFP/7nneQy+eJRtwuzC3n4s98hIFsjmQsigTK Ekme/dSHSWdz/GH9ZjK5PFtaDjNzuCebZgCWj5h9r68UDeGRrqvAKPvDxrzBs6lDIzjE8XAKY8Bm KJDTGM0Vc5RjS88HNlxa6rdaiONI3wDbjnXyganjmTW4hiXNLSw50MIz+w7yD7OmUBGP8/6nlrLq UBuLD7TwP+efzaIRQwFnx6PuTJbLxowgZ0s2tbXz1J79VCZitPcPsPloOzkp+dzZpzOQzdOTzXLd 5LF8/uzTuX/zTnZ1dGEJGFJawtnD6vn3Zas53NuHJeBYf4bdnV3cMnMy8YjF115+hb5cjv5cnltm TOLKsSP53a4m/m3ebBrLS/j00pe9cs+cREU8xi3PveRWSUAgpcS3SxKeADvr8nouL+Vh8AVkhQhx KjCHTKS3H7Byo6r9gKVKotLpDFTAkjLppI+oUvE4N5wxi1/d8h5evPPj3HvzDUZ6Y11kQ7FUUxkd 5nM+USuKJSLoVFIgzG7KcPlq8g3YmAmXfM33TcSiXDN7Bkf++4vccOYsw7WuRpeMaZWG2eqNsHnv ry/rEGq0q9qTU28cKVSdQxwPJx8FjSFQmjgUPF+pcq16t0n3VrfRC0FZLEZdKsl9W3bxZFMzmbzN nq4eerJZfr+zCSTUpVJsOnqMuBVhVl0N5w1rcAouBIlIhK3tHXRn0gA809TMN19eT1v/AJYQ3DR1 Auc1DgEpKYlGuXT0cCbWVJGzbQ509yKEYEhZCZ+fdzovH2rl3o3bKY3F6MvmSEYi3LtxG/u6elD0 l4xEuHDEUK4aN5KosJgxuIbLRw+nI51mT1e3U+7d+wFoLCvBNoPOvNpD+uhUBlxbQfF1LRERxkCb EELEhBBThRBjhIMyIUSjECL+6nfrPKJCiIlCiIl/zrL+n4DhfnKGNZxgIan+Sc8C9Mm1DiqSgeyE Doswr0h39ShhxjQEvF9Fy2bjzX833T9aVIIn1MMDLmFVDv18Q9aKxqh4NKnvF96QmR70DXigHA98 4diQrtfQaRXiNeDkCVhZY2YLM7RiBRG4R2oLzzmVtyVHB9KMrijnYzMmUZ1I8Ifd+xlXWU59SYqb poznynEj+ND0CcwdUocQ8Ojuffx2ZxMCqEzEeO/UcTzd1MyD2/fQ3p9mWFkpMcsiHrGIWhaJiLf2 eW82y4Nbd/Ns0wEGlySZVVeLlJJMPk99aQm3zZpGW/8AUSF4+dAROtIZ7jhjJhOqK8nbundAAhFL ELW8N0xFo4yrrHDKPXksV44ZwY2TxjpzgT2fvFd5uGPjpqtPZR4YUNKR5qE0awjHZ1kLfBtYBFQA VwNXARcIIWKvMasS4J3AvwszRPbvEVr5dQlVKk+LF2ykI6Fd3gp4oAFjP2DUJ8hAqp0LnbcaK/YF JRkE7ydIATqwyyRa8D/Kb2tipHaO/fl60dvG9CN/cby7i0Q5a9EMlF8pME6FqUFfWfhaIUIUwcmP AStPqtKmXU3QG1dyFyYXaoFy1RjdtXbc1bGiwrES2wfS3LN5ByPKS7ll+kTmDRnMM/tb+MbqDVQl Etw5ZzrjaypZMKyBu90pB/OG1lObSnDztAm09g1w/5adJCIRptXWcN7wIVTFY8wfWs9QI9qxJ5vl ng3biEcs3jlxLPUlSUZWlDF/WANlsSjvmjyOJ/bsZ+bgGs5rHMJDNbv51uoNRCzBlEFVlEVjzB0y GAFUxOIsGNZABBhZXsYFI4Zy6ahhPLPvIN9Ys4mqRJw7T59GMTVYuB2ZDHw7Fw0PgVtVao1dqXuA EDjVkwRGAT8HFgA3AP8N3AHsBzb4bhDCwiHtwe53L7AauA/4Lf7+++8WKogK8HQ/6VlzhWqIf51k k4OcChOeXqkIR2oxN6bAKxeum8anmBqZH/dP4KfK4yZziVHHVARzMaZQeWuxS+N/52bp1klQHj03 tUrq3zPYLK+TttALFiKEwikuRemOFrmrPknTHeNqvEpTDm4uoCCEYGRFKYuvvpi8bSMsSy8/+bOL zsVWlrblqJI/u3iBsxRlJOLL56vnzMHGCRCJWJ5B/51F80EIJ28BDSUlPPfOy0FId6Utwbsnjefd k8cBkiGlJTx97WW6nM+/8zK3nGhV+IHL3gICJg+q5KcXnQMS3j1pLO92N2f42cXnYNsqShSvPkCH VHpuLnT96Z/Gt8/wKOICDIEN9AHlwPXAPwB7gQzwNgIEjEPYV+BYyuU4FXo1kHPz+fuH4WxxfTD4 vFZC27g+IlNt0M+Zbru1nAR6JS1RmK9DwsXtwAKC9P8XNMGLmJNuH2SYwSqYEeV1M25Ui44omfLm NGuT3JVDw2J30wvtRTDyQY2de7+d3KSbpQj15hDHxSm4oCVI2yEJUyLdASQVvCHNj+02Ri1L5j63 zlKRFrhTdZyTlgChS+dIU8SytEXrfwmTfA36cl1BVYkYc4fWAdJZyUoa6XRy5WZ2TmgPkrI8da+k PgGNXJfb68B89SV823ojbYmU3vs6deVNPdKuLDNYJkQxJIE5QBbnD3j0OOliQCPQAlwOPI7jvn7T QFmkHuGoFul+pPCsXeHpjgJ8Y7quc9ljZ1MUDK9PUd5RQVmyMIHhRPPl478fv9gGidnsHkTBbd79 dpCahTYecBURT/tA92WeCawTFpafUF5DvDacGgGbS1ECSmuUUnpuHdf6dWIYzMEQVwLMY3XNt7SW /3KBbywooAUCa7svKJhQXcUDly/ybTFY/EGySD5Fnq2kUJj3m2WF4Anh9jhKM1ZuOW1XSC8KVZqa tGtRyKLlCIFjwe4HSnE2PK/FIWM1Vqy+BY6l+zUc9/OTwNi/Qnn/KtDtymcFm/wp3WUpPaIyI5al mi4kvVFPMMTFzcgkOp/rWhOYYvbA6LH5LBwKUzMupD/Z8cXe4EN/EJbbQ2n/NwaRehnpe9T4uPEg 06sljRfTQWx4wWpaR1dPD8U2xHFwamtBS7MBGpdQY8GyoEGb0xGckH1Dg9QtVhbJ1buWyeVZe7iN bD5fUCwpbY7297PtaIchxX5izefz7OnsZMn+Zla2tHK0P02B5BdmjE+izHJqlTqYXpXbewfpWhjm PY5FIl33tK0FVpgmtNnb2OF4UhF0A7/HGQNeCLwD2CqEqATmCSGSwLlAHMjjEDY4JF3YkP5OYeqE Ph6Sij7cJSkNMvUztfQ1dWEcaDo18lXR08qXpL8DxKjFKUBSwZ14i8JQKLSnTd0vzB2OhbZoi4m5 Um49Pc0l08DSld69wnhXL+pbVay6Nbg2QogQQZzCNCQHes6bHmyROmDIL6iuNazD+UGPfWo1MSjt FFqhUtLWP8BnXniZrkzGn05K0rkczzQ1888vvqxduabYSGyae3v50rK13PzkC9z69Avct3k7PXqD 7gBk8KPeM5BAXVdrTQc90+6xQCIC0SyehlxMJVf1hxbucC1oHwQQkVL2AH8E5gG341jCfwRG4IwL VwG34UQ87wYGcCq6B9ip8vlLF/4vDVOclPdFGiQpjX/+VWBMfVPqtupNXXLl3nTAuueVzEiMfqKA 2c17CvVdswympatFTwaikN28bCmd2BBUPk4GxfZKUTd5+/cafRreT/X6yqpVbydcy17Vgb+7KIgT DxFC46SDsPT4jjvm6jU6FfXn+biEFj4vSEFYKmRBpfMasNOqlWopDEJzMowKGFKacgk3z9rWo2Ty NuXxGGMrK9jR0cWaw0dJ5/JsPtpBKhaltb+f8niMSdVVvHDgEH/cvY+7zp/LjmNd/Gb7XhY2NlAS iVKeiFFfkuJwbz/dmSxjKsvZfqyTowNpyuMxpg+qIqq2QywmUua6c0EfGf7l6py3lj4B9TatQAu+ qkVXxfetSRvCUXuEEGOllLuEEIuAuJQy7V7fgBOcBXCt+73XuH+PEGI/MJ83gSVs6m7SZTbPPgQz yMrTDDEsXMNjYwwvFWyliXevI/vOkX8bxEL9uiBIS/i/g84xYSYsakGj5cs7Iz3dX7+rK38qyErf YZTXEG1T/E2VWQZPqMNwHdkQJ8DJR0ErQdIDSs63MKw/PQdPC6IhBMryM6IIjRuNBwXUXQE56aye lcnnWdFyhHc9voRhZSWUx2P88IL5muwO9/Xz3ieXMKmmiqauHvK25OErFtHaN0DEEjSWlVJfkmJs VTkCwd1rN1GVTPCZOdP51pqNZG2b908ZzyeXrKA7kyUvJd9/y9mc2TBYvVChwapUdLPjsM13N29U deQuQxmQWs9iQAe+FA1IefNC4liyu4APAP8inYpKn/CuQlQCNwLb+BvqJoUQCRyLf4l8TRPEPTez Saj6qnAXztBia7K1klf32aibleIoPL1ZdQdeOY0nue1Zt3+Vxne5COHKQEJ12iNO5/n+/E3F1Swv 3lW3+/Hv22sqwb5yCM8xoJ+nKkZQKJ8qfei0CnECnNJuSMJQR7V3xrBgnbEYqd06Dn8a2xSixoc9 15eTneH+CYzBICGdzbPpaAcd6SwvHjxMxs7zoWkTqIjHaOru1enzts3ezh4aSlJ8f9HZtPb3s+Fo O5ePGcGE6kruWLqSzyxdyYbWdqJCcGbDYH6+eSd7O7v52eYdzGsYzH1bdtLWn+bei85lRHkZj+89 gI6SVlIaJEcdNSndGDAbtYuT57cyosONt/cUa6ktEqnzVFdCAEgHh6WUV0op/+V15HNUSvlBKeUH XhuR/Z9BCngex4r/ohBizImTC5yZB0E90VOmvRWsPDeuOZqkv9XKWMJ/Hp1OubFdkjRFRJoH6rwX XX3cshdzWRvnnXIKrbgK80Wlfv2ikNJZFtfLL9DveA8MWMCGy9uXH6rr8xF5iBDF8Lp2Q3JOGCLq kqbSKIXh1vI0TKG1Ru2K1vmY6nlQoxRaLhIRizl1g6iIx/nRxu30ZnP0ZrK+xl6ViPOp2VOJRyNU JxLs7+phclUlX5o3m7GV5Sw+0MLHnnsJAXxo+kSEgAe27qahpIT5Q+v5xdZdjKsqZ0JVBV+edxrJ aMSrAKNMhWPDzltqR5ZwIyRlMA0g9QxCvztLGi5pt3MMpyKFMKCaygjg8+7nT8AvgCcobGkFlq/T 5tz/heFxcV2xypQVxo1qty7tkvZZq66ibU7DM13RAYtUmvOdzFeS7j7jqr8wxnX9r66ebdwv8eIk 9PsEsjdKpPJX83u1wqvSSb9O7dwgfV2emh9sB9ILg9RDCg5xPJzSWtAFDcpokMfbrNt/QlnH6qRp Cx7vsVILVS5vc6ivn4tHDuWD08bT1N3DY3v2YwUoKqbmDQPZvM0ju/fxvieXsqW9g7i7VOWQ0hKq E3HmDanju+u3cPHIoVTFY5w7tIFlLUd4dM8+/mHJSv6we39B+QvMBF1O25fMdIMZejvmKjleNLSn mHhdlAoGCUU5hA+G2cY84PvAVpwVCgViIgAAIABJREFUwc7ypfSMQY9QNXF6yrOWb+m3ms0HmpZn YVE8I9EMXvKCm9y02pJUB4qsHItU/w5YyOZSkubd/hf1gqdEIIEqv2+dAsN40MFaqphBEZdGdLV6 DeHVq6eLeMp5qDiHOB5OIQhLyanRqi0j4F8LlQjcBJpKpKfZmr2CozkH7EHDHZSIRpg3ZDDl8Shj K8v56aYdbGzr4OKRw7h91hReaW1n7pDBJCzBvCGDSVgREHBGfS1TaqqYWlvF8pYjfHXFOiwhuGL0 cG6dPoGYZfGPs6aSs20+PH0CpbEo144fwWN793PX2i00lKb40NQJxesjYLo6VoJ50qgD3I7I9gTT S+UMGnmCbgdvfcMghLgQuBW/AhbsJ8TrOA7v//PeX0xxVpHcSZw1sa8GjvT29q4EZZW5ZCGLSqiT uZtQmpasac261/W9evil+GuYdm5QodTPo9BSVbElwaZvWuq+5yvYig09W/f4hkChFPoue3qz4QVQ J9XOUYEAS1H4pqHaHOJ4OHkCJiBUOoDDbXg6HN+QcuEt7+YQrfC0by8Jpmh6mrbXfIeUpHjw0vNA CIaUplh89SXkbdtZBUvAxOpKrpvgDIc9eNn5qAL85ML5Oo8HL3sLeTsPSCKWN/vkzIZaHrpsoRau 0ZXlLL76EjL5PPFIhAJTwCedaNLVHUoxRcSQbOk7Z/YIhkViPvMNsn7dNZG/CwwCDvhfyAf5Oo7/ L99vv4Y0f87nvxH3R4HpFIeNQ9A2sCsSiRyA47C7cpeCtvoUsVn+BgoIcrk824+0uqvOSSLCYtzg QYiIhVKgg67j4Bus3LOP2SMaiUUsf6GUd8vO88r+g/RmsiRjMWYOayAZi9HZ30dbTx9j62p96be0 HKaurIzudJr+TBbLssjbNnlbMrymkspUSr+vfqVCcxUlk54d76xnjy3Nm9wZHWhDwnlX4xWll4/U vukQIYrjlAjYp+P5/FPCa4BuS/Y3Xzwt0j2riVep6DqR5R4ZcwyDKrvAW4JSCZMZhgloi9pQ5yOW 417zRS37b9JHccONXTSJIbyemqwrxO2QpC+tCafKTJvAyFe5899Y1/OVwHjgGinlw29kxiH+MhBC VACdgdN5HCt4F/Ag8AyQTSaTk8EkWq1jOlvwGpZrcCzYe57z3dk/wEd/+TBDKioAyObzfPz8czh/ 8nivjQY9W+bYMvChnz/IM5+8lcEVZUpf954vJU9u3ManHvwD8WiErv40X7/mMq6ePYNlO/dy/8uv cJ+7z7B6xH89uZjr55zGkh272dDcgiUEfZksQsA/X7qIBRPGuH2O8yCfO1t1VEb3Yu53rE8aP7UH T592ZN4vorKYqIcIUYBTGwM2AoIkfmEFw3GkGrMxkCLxxnQ8TlTR0tJo6DZGiJbxeInfPWtYieAu iIH38UpZcOj7XfR8MeKVzopUbnrvNu+EOb7kJ+TASLfESBN4D+mtjGV2Em8APoPTSf/2DcsxxF8L qsF0AT/C2RVqHvADoM1LdbxGbzY750BHObtp1OpQUsJANsfKPfsYVlXJsOpKNh5s4YYf/xyk5FBn N0t27Gbp9l20dHQikbR0dLF0+26Wbt/N4c5uAIZXV+oibGk5zJLtu1ixex/ZXI7mjk6u/N69DKms 4NvXX8mMxiG8+8e/ZE9rO1sPtfLIuk2satrPkm27ONbTj5CCQWWlVJWmGFRaQlkiwR83bGF/ewcj aqp5ee9++jM5QLCp+RCt3T3sONzGxoOHWbJ9N8t2N5HJOsGbTW1HWbp9Fy/t2kvWzhuV676/+q26 EV89BSFcpVqYGkaIEAU4pTFghEscQjue8Mxev9Vrbkum6F5r4sKbm1hgKvs0aAHY5PKwv7eXgZxD wLGIYER5meMidmFLSftAmo50hnFVFRgX/Pm7B5m8M7Vp2qAqokKQsW0S0YghbUaBbO+nN3lI+LLV SkPQGLb9VrKqG3MITa+Vq8eSzWtmzZ4ahBDnAnOBj0opQ+fY3y4kTmt8GrgHZynOHM5ym6nj3yS1 x8knssITMx1tHxyTNUj7bTOnIoSgq3+Al3bvRQLfXfwiT2zcSjqX4+Kpk/iva67gO8+/yO/WbiQZ j3L17Bn8y6WLaOnsJm9LDnR08Ilf/Y6edIaDHV38/OYb2NXWDsBjt3+QZCzGgnFjqLz9szy0Zj2V qSS96QzffGoJL+1q4vYLzuUTixZwuLObtp5ePnnheQA8uHodHz1/Ph85bx6Nd/wbMxqHcsHk8Xzk /z3EZy+7kPteWsW+9mPYUrK79Sjfe/c1nDdhDF/+4zNsO3SE1p5evnb15Vw+Y2rh+7sVZnqlilu+ wuvSQis4xAlwCmtBg8+a9H17lpyaiyfMJRqlubeo1Javz6K23XnEwhsRlu46yZ2ZDF95eSO3v/Ay n1/xCp/50xqe2d+ibgRpk8nlWd5yhO9v2OYrj/8FvPHVtr4BPvPiKjrTGTrSGZ7a12yk99I5u6d4 jCg0nZqWhDG/12fVu9YEXgynlPjqycnMcOFLj5S9z0n/tYL4DNAK3Pu6cwrx10QfMEJKeYmU8ldS yoETpjbXOJbC17y9NObYpzBaq/vPC9Tgi48+yb89+hQv7tzDxPo6pJT8bNnLvGfu6bz9tGl85/kX ybvnLpk2iRvPmsPzW3eStyUbmlvoz2X56YsrWXeghYc//D5mNA7h4bUb9BrvyWgMJFiWRW1ZKbta vQ2uvnD5RXz6ooXc8dCjpLM5ntq8jU0HDwNgu2ulD2SdseDTRzbyzacW09zRxYo9+zhj1HA2HTxE W08vv77lJmY0DuXmnz3AS7ua+MWK1Xz64vOZ1FDHdT+8T0dPB2dneKTqjRb7KlF6vZa3TGaIEMVx ihawM16jN6MWINTegVKCZXnNTo2vKMvZ1ST1fGDHFNYWY1Hr0f3dn8vx7IEWqhJxplRX8mLLET7y /HI23HAFO7u6KYlG6UxnKI3FqIjHkFLSkc6w/ugxLJzArTGV5bT2D7C/uxdLCGpTCYaUpujP5Xmi qZkvrlzHqLIyIpZgUCJBbTLB4f4+ujI5JlZXotzfyiI1ZkUWryvjwPtZKJamVq12nTlBhicNIcRk nG34viil7D/ljEL81SGlzAPNp3Cj57UyHE86cBD0CnWeo0gFH6Gb3wMfei8VyQTffHoJX3nsaQb+ P3vvHW/HUd7/v2f3tNvvlXSvuqwuq1mSLeGqggADNt0mBkIw5EcJJDhOAoE0EgImQAwJhE4oIZQQ IHxxCcYOYGxjCVxkWZZlNUuy1a90ezl15/fHlJ3dc+61dG18LWs/eh2ds7szszNzd/bzPM8880yp zNJpU/jJQ9vpHVaPVhAErFs4j82PH+CnQztYNWuGFqMVHnryMAs6JjG5uYkbXnMFngcPHFA+gU90 9TCjrZkTA0P0DA+zYsY0m29exyQy6RR/9t8/YahUpDGbNX0S7yM+9torWH3Dv/LFO3/Ngo52Wurr GS6V+L0LVjKlpZmrzj+Pu3Y/zs5jnapd922hEgTMbGulIiv6neZY9dw5bdthhO8qY0Ug6mSaIMFI OP1AHJYk3JP2P+sVbRKFv1USu7DeMchGyw2dJSLhoPX/TZk0b140h99fMJt7jrRz/T0PsLu3jz+4 49fMb2kml/K4et45HBoYYrBY4ps79vD5h3cypb6OGY31fOyS8/n5k0e4cct25jQ38o8XruT4UJ7u fIEvP7KLgWKZrz26h95ikdnNjVy34lz+ZetOAim58dILYkPKXVblSAymP0biUdXAqmP1MjQDXGoj QVx7HzPeBwyjPKATnEWwViZ37BlGqflICdzIUdrNyI7ZX+3cS302w4NPHGTlzGkMFArcuWsv/+89 b2PrwcP8/U0/Y7hYomtwiHdvuIQtTxzi67/+DUOFkq3PlcsX8+7v/Ig7d+3hQz+5jRcvXsi7N1zC kmmT+cRtv+Cq88/jnj2PM7W5mRctXsCvdu0F4I5Hd7H14GHmt0+iOZeL1ln/8oWHRLB46hSmNDdx 4+138uP3vA2AxmyWHzy4lQ3nzudbm+/nornncO6UDuozaa69eA17j59g/cL5eMLXfaVLl+4ba8RB rcPPJtSb4NRwmgQsQ8nZmInj874xr2gZEbWjRUUe01hMV5Um9JIWAjyhNry/Zd9BPAS3P3mE1R0T aEln2Ns7wJzmRt63cjm37j/IpiOdHBkc5ob7t/H59ReytK2Fy2/6Od957HEE0Dlc4H2rltCaybC9 q4eGlM/frF7GdXffz5+vXMxPDxzihgce4dWzp/Otx/by/ZeuxfVVdgURaY7jBOw0WVucHdO1m1SZ oYV7bLvFTDqPfUG/EGIq8GbgK1LKkTasT/C8hVn6F4Y5heiQtMqcUYll7JoQpP0Ul82fw1fv2WRL /sZb38SE+noumz+HT91+JxK4bP4cfN9j1oQ2vvHr3wLw+gtW0pjNsHbBXHKpDNesWcl3f/sgH7nl DjKpFNe/eB1NuSxfeONV/N1Nt/HRW+9ACPjYa69g0eR29p/sZu2Cudx4+y8B+NjrrgAgXy5Rl0nb d8zaBXOYM2kCQko84MVLFvKD+7eyYeE8kJJKECCAG269g4zv87k3XcWCjkm8/oKVtuy/fvlLwpFu ZRVRQyAOp5LQJvqIdV+SEHGCUTEmE7SJHFNjBiQcyEb7FURXF2GeVf0SsOtdY+5MEr3oPSxVShXn uRAEHBsa5rKp7bxt8VyKlYD2uiyfW7eGibkcdzzpUUEyXClT56dYP62DciBpyabZ3tXDsgmtTMhm eMeShezvV96ZvoDJ9Tl8IZjeUMcLZ0zmw/dt43u7D9BRV8fFkydFzEq27bIGmdaa+dHz3zIyRGXU pOX0YZhNYhYTSjlWCuZPUUtUPj3WAhKcyZCx5875JcMZIBci+lQjgfamRm7703fFrqu8P7v+XQSB tGvyBYIvvfn1VPSUjVkuePv177JCwB1/9m6K5RKZVMrW66J5s7nj+ndRCiqkPA8h1HTWS5cs4qVL FiGRBEGA7/nsPXGSY30DLJ8+1RLj7X/2bszU0JPdvew+1slLly4il06rdki4buM63rH2onAaDfjC m64mCAIVmtIRUGzgjRFMykK/CwNzPSHdBKeBMa0DBjBLFtCmYkuuds4oHPARc5b29A0t0w4BWelb RBlO3Y4gUAPmHUvm89Zz52IS7e8bQILdLtATgozn0ZpJ01GX45s79jK7uYHufJGXzJzK8eE8zZk0 yl4UDhcPQb5c4bfHTzCvpYnz2yfwuW07+aOlC0j7Hu6yKFdCtsejaKnW4iedV1qVg5gSNOzcuhn5 NSNrnRqEEE2oqFc/lFLuG1MhCc5wCEwIrMg61nCiN/SCBitk2ykgrRpLYXRpV3s2gSeEWl/v5Afw a0Sscp/kdCptz5p3gBCQ9lOR1OHbROB7PhLJtoNHWDt/DufPnB5W3t5HsuWJg0rLfePrbNlXnLeY cya2hda7wBaM8MLpr2h0DaedsfXERig2/0drmyDB6Dg9ArbmlqiU6NqyjFOWIZKISFg9cazHi1GT Q+cFoUk4HAeSjC+4oH0CE7OZSDlZ3+PiyZPI+h4pIZjf0sSlU9qZlMvy/vMX88VHdiOAl58zjavn zeSOJ49yydR2JJDxfC6aPIk6P0VHXY7FE1r4yvY9fHH9Gt68cDYPdnbx9iXzquJ7RIjY9eKO9Je1 B1RpulXHutT42mGh++ZpLBp6B2pT+n8ecwkJznBIO75sGFnHXGpIz4U5tsuWjHYnotYa12LlHtqi zXMcl0zjhCycEeW8T4yubQnPSAgIXrVyGa9asTRye2sqRvLK85bySr2cSOi8H3nVy6O315srCB3j 2Xh8hyJvjHBDdThyzWj1YRwsl6RJkKAmxrAfsCEHZ0Bb4tASoiM1W9j1ra5YrR7zcGyGozWuYSIE 7XU5vvZCFWM+fOhhakMd//3StfY2V8+bydXzZiEEXDN/Nq+fdw7lILDrha+aN4ur588CVN4fvGwt ZtD84tUvAuDY4DD3Hu1kyYQWFrQ0RYmzhjkqPsZMy6oj5zj9IqM+1JF5J0eSH6tALYRIA9cDv5RS PjC2UhI8f6DJJpSWrbBsfhp52HkogXD9sHAER1cjDNBr+s0QNgsc48O4tqjKgRMnaa2voyGTYevB I6yYMZWU71OuVNh++BgrZk0P61wjf5zl7D7FRnBQlYy2DQjX7IYVNWRtVytE0us3lns7Ed80wrwL E/JNMDrGsB+ws8g8fGyded3oFSsvGuKyH4mQxgTsaIMSCGR0X0+b39lNSEu5JokQ4QNvlwgZ709w gnWo+wWB+liJm/B3JZCcyBc40D/IP65ZjucWLFSvSTO4HTlZOPU0mqxw5oRd8jW7Rkk3vTTnna0c 7XthTGsK3wDMBD55uhkTPL/grv+10egiQrA1uWDjPlU9bm6kLKw2HNEUhbRaZdXsinm+Xe1Xp7vx 9ju5Z88+uofzvOUb3+Wu3Y8DKvzlO/7zv5FBEB3oFlHV2pQnnTGlzkukqZdbH/OeQK97Nu2rxZxm TLtasEvU4VsgTJ4gwSgYw37A0s4DmSc5lJrDpQ7m4Y56SY/ghSnD2VURTanLcq460mjENKXPGwm7 1rImwqyhadu+lUIR1xOwZEILP375OisQxE3JNrUdZNHRVjX4XAJ388cGe0Rzjgg41U5vp4D3A9uk lLedftYEzy+YdfvmNzHTqYK1STmarPGgRqCEY1eJFWH5EiWgH+3rZ7deW7tgSjtTmpvoGR7ikUNH kRKWT59CW309vflhHj54hIZMhpu3bmdqSzPLp0/l8c6T/OE3/4tH/uEDFCsB2w4dIZCS430Dttx5 HZOY1trM7mPHKVYqdA0M0VyXo72pkb2dJ5jS1MSCye0UKxU2P34AAcxsa+WciW0RgUEg1AZKERIN h6RwVme4/WL7KyKnJIyb4PQwBi9oxxlBuCSKnX9xTkQdGnT+SHGWCfUkp3HiMtdj3+4GZY6AW23a cqR9d0YnMj/jvECiywsibxaM/lkbcoQj53xEk691P/dYOjuwuER/epGwhBAvQ+2Yc+2p50rwfIZZ W69+x4YremwZadpJ5z7LkTlhok+/OfuFO+/h/z20jbp0mteuOo+/vPyFfOve+/nPzfcTSMlbL17D ezZcxnc3P8i//vwuVp8zk2P9A+TSaTztLS2E4EdbtvLypYtt+Z+/8x5+5oS7/ORVr+Qjt97B4Z5e 8qUSpUrAK89byk1bH2HmhDa++/Y3c/v2nfzp93/M9LZWFk/p4JNXvZKWujobFCScCzbkKiOHVe8F a4pXYW+jQzJ8ByXab4JTwRg2Y9DQVhjhDlBpwjBGPYasadbmNXYipxzCAWwe/OoN6K0dy35s7Fp9 XkoVNjIyMqRU8z+OyckcY0Jl2uIlEVPZCN5PrrHJVYKt6TySOGK0sgJMfI2vMG2rUnWjwsMp4v2o 7Qa/dzqZEjw/YZ89NxSlIwxGzLDmmpkegQghy1HGciUI+Nam+3jZ0sW86cILuHPnHnryw/zVj2/l LRev4Y0vOJ8P/vhWOgcH+Isf3sTfXvkS/urlL1LLlJxBct3GtfzRt3/I5n0HbFW/de99vPnCC3jV ChXuMggCHj18lL7hPN/6w99n26EjHOnt40u//3p++sgOjvcPcM1Xv8Wa2bO4/kXr+N59W/jt/ie0 pk7EsTL+upCm/RHROwzlWR0gx317xctK2DhBbYxxGZIhR2E9Fsx6uFom4NDMG9OGI/piROTGaqoR w5CjMUeqE5qoTZ2sd7J+e5iXihEY1OnQXO7s8hm5X42qRuoFRPdDjpmqqwQPG+/ZlcCNA4smf+He 35mjPsVxLIS4ANgIvE9KWTq1XAnODjgmZDNqHCuQnSJypcsY11Tbk9QvKUAGAZctmMvmfQfo2T7E ipnT6R0qAHDXrr2kfJ8pzU0c6x0A4OXLFtNSlyOXSjkOnvDeF63lhw9u5brv/Q8AxVJFhbvcGoa7 lBIGCkXeue5i5kyciO95XP+i9czrmAhAqaxiSx/o6ubHW7Yxr30i3UPDsbFvxqG6t50W122PGq7C OO5GiI5bCGpz7RgmjxKcFTgtDTgci1Fng9AqpbRfM5Ct5msnVLS07ZZlrhsnCzMg9KeWRincBJG6 SdTa3sBqxuZ8KNtHCVGlq5ZcnSS4a3LDemM5MdIOom2x7SAmjOgyrOwsw0i5EclcunU7ZUn6/aj9 Yr9yqhkSPP9hn2IZfa4joSq1IKkuma1DnCfQeczDx9F4+0sK5TI9g8P80bpLeOnSxdz2yA7SnsfM tlZeu+o83vSCVVy+dBHzOyYys62V7/zmAW5/dBeDxaJax68ffg+Pb73t9ynpDRb68irc5fsvfyG/ t3olAAGB3ttbjczGbIZ0KozfLBAsnz6VtfPncO0la1g1czqXzZvjdgBmBApESKi2bdH3nGm/UTTc sem+5tz+VjVLNOAEtXH6GnAQqChXjtuxkQbB0QGtyuk4D7mj2HXOMgE9XA3ZIW0XMgiiTiP2R9R5 YiShM37dDo0RNdyqClTni9U7lI6rB17cGUw6I1e6563G6+obp4TZwNXAjVLK/tPJmOD5DddIGj5/ UQ3YpFNBO0RIv5LQ+5mI8SicOxZQn8kyc2Ib37xXhaC8+vwVTG9r4a+veAn/sUmd27BwPvWZLH9z xUv49m/uB1T4ytkTJ5L2VLjLIAiYM2kib7vkBfxm3wEmNqhwl5/+vztt+mI5YN2CeczQewxfNHc2 WR3Y47L5c8ilU3z1D67hfT/8CVsPHqYhm6W9qTHSJ1Vj1Biw3OMgajE7FZNyqBlXk3iCBAYi/jAJ tQWI2Ve0HmgC2qZNm3buKy56wdc/W192nidhH0ohYg+ZMckaaVE/jDaZdbaKEnc0v/PtXiIcICHx R9PFA9nUmpetdT1Ou1VDrcq07NRmhIEZl5TD8rWWXH0TO8itHi8lJyS8u4euW2655b3AcaALtRl7 H2qjhQLwKeCdwGwp5ZGaFUrwvIMQIkU4bhuAFqBl6tSpi69cv+4rH1+zwlphQD+Twmh+en2w6wAZ StGhf5I7fuP3d9IJ1FwwgO/5jnVMvQU8z8NMGwVSaser+CBw6kIoEMtApQ8FYDOg4lNWWjPWBQSV ir5PjETd4WvLjP2QegmxELGxWj12ZY2Dk4Uif37vfV233HLLHwEnCMftIGpryUIyVXR24rQ0YCUF SksKkRXB7pwwzvDR5qGQoKPMaDXNWoRYaz1e7A0QpjeaaXS5TqghY6/b8mtcjw/o2CRQdTpnyEVe Ck7d3f2Oa2q+IqyHJWtrFQgcE/dTStITgD8Evp2Qb4IoHOcqcCxTIcmGRlP0Ixgdk/ZAxBcNEskn 0cSLcwKcte3Ocy8MmUantGqMKnVNk++IgrIZR+HcDoD1rq6tvYalCXDmooU1QokR845YFAjl4zn2 IHYJnu84/XXAAeApMrDSZk3HKPuf5mFN0NLNEx10Vb/dB95dXyxi12I3jmjDccXcELWID10lLEQI srpBlgTj+m91D4T53ZCcLvHWSKoPdT/VkMSfAu9GaUA3PmXKBAmoJd86T7L7/Am0JQuEdIjXNUU7 MrhdN+yQb7RQo1ZXP9SuQBoXzKvGQlxQJnocl6er7iWpGtMRwUI6SkI8X43jcPmSyixkjcQJEmiM wQvaMqAabPa39ufSmrBEahcvo3EaU7U6Z7cz1CfV0iU3xnSU1kJS1vHkYg+1dAeiO/DDWke+4/mF MZFVDeh484Pqcq05z9Fgpaqjo1NorUJGuNW2VoZtNuVUyRmjK8A5FAHfKqXcMWrKBGcdJGo4GmI0 JFpNTNW6pw03KR0v6WiKSPa43GhwsLuH3qFhO+7nd0zSOyGF2H38BAs62quNPTGC3X38OAs62ikH gd1pqeZNY1eirTPmOhkTvqv07qcs25kpqj6ZIMEIGNs6YP0kRzYokDXW7eo0VgqULtGYgog8tUEQ 4IaQs3qyqzk63sXu/e0nCI0+Veni6e2hjJZRq9xYejnKsdX0Tf31emMjP5iauRQtMIKAWqSsXpbO 22D0sfwmoJ1k04UENeAKmG6kNQPXtUGtdRWRc67iGX5MOvMsO0OF6OMqpeRf/u9OPvOLu/jubx/g S3fdy63bduCMEKSU/PCBhzDPfmRM6nRSqu0If/jAVgB+vmNX7Ppow9gJuenuKoHpE7N/uYhZ9cLW jPR60HoFNmRsLUtXggQxjCEUpfpf6IcdL2QHIbzwoTMSYUSSFbjbFIYh7lzTtHszx/gTC+FT00zt QntLVzdAp/e8yHHcO9met7V1tN1Ii6pfNJG3laPGuodV66VtPqMB65IDndPZF7kGBPBe4LfAPbUS JDi7IbXaacffqKsGZGzoOK5NMbNMaMGKFlPrKf3+/Vv4zDWv48WLF7G3s5P1N36OnvOWsr+rm0AG 9AwNs/qcmQD0DA3zyKGjgGTFzOk057I83nmSchCm6x4a4qovfYNNH7yeSiVg+fSpCCE4cLKLyS1N ag9gZ3Dad5apoB5yMjbWTwu6oUGsI53ItiP0RoIEYyDg8LnS5qhA2JPhVoRhWmF/yTCfJpPQE1N7 E0b2AtZkUzVJFSM9Q+BV9QtfNuUg4Ohwnql1dTw5OER/qYwAfE8wpS5Hm7u9oXO/YiVgR08f57Y0 kfG96hsAat1zmFdoKTiitUZkEmn51M4T2Z5xMgjUkmanIDnyYL4CmAf8da2LCRJgnjtDxO4lYS9H jiNJ9JhUwy0Uhmvyt31WzQWlbfqeR1t9Hd2Dg0jUsRSSj/30DjoaGznc20exUuHFixfxn5vv53+3 PQrA761eydsuuZAb/vcOOpqbONzTS7FSYWJjA9lUiu/ft4Vdx47zz1e9mpkTWvmn2/6Pf3jly5jc nAorEb4wwi/T5lgYyshbbgRWjiQ3Conuk2ii2LkECRyctgm6SlO0Fwi1WMKdjGTsYx9tERJytSk3 CMuzwQHC+4zmjeiagEyq3mLj3uC2AAAgAElEQVSJzz+6l+5ikU9v28Vnt+/mP3Yf4Bu79vO9vU8y XCrH7i8JpOTg4BB/e/92Bspl9wYxlRfbZisvGBfMiDIcbT/GHOb0mzmPxLpORkzwI+OPgb3AT0ZL lOBshnmSao/N0bIZA1VoknYi4emHXjrjLWLSNaZeAY3ZLJ+/89f8Yucevnjnr3nRuQvx8PnZ9sdY PXsWX3/LG7h7914GC0U++4u7+N/r3smtf/IO/vJHN1MJAn726GOsPmcmX3/LNdy9ey+rZs5gcnMT H3rFS7li+RK+uem35EslbnvkMdobGrWUG97fCAPSmKpFaNaWVYM6tMjVMqQJ+58rQqsM1o9EVL8u EiRwcfom6LgJVgBSIIUTThFAeKGvlp0slmpAChk6ZVmhUzr7dYrYgIgqnoOlMg939wEwu6meqfU5 egoltnX1kvE9lrW10JBOcWI4z2M9/QxVKtz6xBHede5cbj94jM9esooXtLdxYGCId9z9AGunTGRR axM7evrpLZSYmM0wt6mB+zu7kEia0inT+KrBpIewJt5Rhpp9eRmtNmoVMMdBICkGAYWgQqEcUJSS YqVCsRJwvBLQMyB8YCEwFcij5n0vQO37m4z1BLXhqKTKyKSfPeEuJowanyLZwK6DFVZ4rr6H5TpL djqlhHKlwrUXr+Gy+XN5xfIlTGpqsKWsmT3LlndicJDzZ85Q7xNP0FKXo1SpOOlC83m5UkEArz9/ Jcs+/AkWT+3gmjWr8HzLjqFQGzYEQ7xRhNNCI/liGs03st7Y5EGTsQw7UCRDMsEoOH0TdEwaVI9a SKihtUdpsXbJgo0TLaMEa7OFg0ro9QzKMhTgPsalimRTZxf/8MCjtGXTXDFjCm9ZcA7f3fsEP9p3 iKZ0ijfMm8kVM6fy1cf2cffRTqbU5Rgsq4Ga9jwynuDocJ6+YpFVE1voKRR5tKuPTz68k858gTmN DVy/fAG/ONzJyXyR4XKZVDrNvcdO8Eh3H8VKQKGiSLIUBIooA/UpVMLfxUpAQX/Hr5ec32EeSeWp zVUtwN/Hzh0DvnMaf8YEZxns8JRmCqT2nDAOb1WVIavnhqMwc8SG96JlDxaKrJgxjda6ukh23/Ns Wt/z6Ghq4MEnD7Jp737KMqAxlyXt+046aT2ffc9j2+EjrJg+jUvmzeYP/+O/2PmPf6M171iUvlCF N7V1pn3C71rhB8xVrR+E77uqnpBWiomaqRMkqMZpErCRJCXE54HsABd2/hJhTM1CeQELk88RsZ2i q+4WTq7a2w1XSmw50c1Vs6eztK2Z7T29HB4a5hNbd/LDF13EyUKRv/jNw6ya0MpNBw7z61du4LHe fjb932aklBQqFb6843HOm9jCgf4h7jh0nL9ftYTPPrqHGQ31vOvcOdx28Bj3He/iHYvmcNuhozSl UwgC/nTTVqt5Gwgg43lkfS/ynXZ+ZzyPjC9oSKWd8yK85nlk9XfaF2RNfp1GfQvyns9XC6n+++67 73NAJ3AS6AF2oqJgJUhQG9KIvzJCvFXOWTGPBC8WYjaQ7sgVdm4Yk8vhsnh8gAvnziaXTjvErMra sHC+cphC6N8Z/uSFa7nxjl8yWCzwkVddgSc8J53H+oXzkcDV56/kO795gPNeN423XnIhWw8eZnJT Iya2daR6MQcO154Vd0aT8Rz6RFD1ohKxd1c4n2zedAkHJxgJYzBBExuwBpaBiXjsWsK28mVsTjM6 4KEmPdv71vs+G6a085GHdvB/h49xUfsEhssV+ktlvrZrP74QzGlqYLhSZkFLI54QNKZSZD0PicQT gneeO4dVE1s4ODTMtu5ejg3n2dbVS1ehSFehgJRwwaRW0iZCno4Fe/eV6+gtlch6PhlfkBU+nmcM T0qrDzX56FKoaluWdC7q9lsR25krR1oh50TgcdOgXwIeoToUZYIEo8BxmNIWKCUbG6FaaDnZEJer NQrHUhUt0/6KEK508ob4/juujeQy1rGvX/sm+074+lveiJRw3QvX8cfrL0WiompJ4OtveaOeexV8 49o3gZR86BUvBSk51tvPr3bt5e+ufGkoDozmKzLSpahhroYPaFSbjixO0P1pz9k8CRLUxpgCcbgS cHxRfmS8ykg2BS8a2DwsL1Kq9aiOBJaUkC8H7Ort533LFjBcqfBnv9nG62ZPY1FLE2+aO5PBcpn7 T3RTl/LY1tXL3Uc76SoUGSyXQULO95nX1EBLJg1IXjNrKn3FEi+fMYWsL1jS2sy+/kGm1+ViFVd5 c75PLVjvZkdGjlrr4gQc/WFNW8TMdwZJPLsETwPuYgHrby9CHwzXioV0AtJER2Do4qFPuhpxaKKO vhNMOfFfViQwsqejMatjLyqsi9DTOFKy8Nh26Aj37T/Ah668fIT7j1SvKJ5KW43GaNd1Ec74dS0N uurJfsAJRsKYCFhG5j/MvEmURqsIVETTh1pedO44jDsRNxcpZDyPyXVZPv7wLuY3N3D59A5mNdTz B/Nm8uEtO2hOp3j7otlMyeV4xcwpfGTLY0zMZnhBexs5X3Dp5AlkPRWJy8djRkM9x/N5Xj6jg/fc u5UpdScpBgH/ftn5HBnKc05DvWm1rlVsPsnWLhSF1UsjiNU82vx4u8yLxmrLWhMOEyXGrATPLMzs kIIeeFKEKwEhJBjry+E8mm46fc0uratS+2SNXzXeGZEz0XQjOk0hedHihbxo8cKqO4xUh6orI9w6 stBKEgomQagqq7FrbGDxGH5VhboDORi1Ugme9zg9AjaPjjNo7RCKmWSiISUdp4Xo8xzhWTvb5KiC MVmXjO/x4mkdbJzaTjmQdn3uuxfP4V2L5iBEOG/1kfOXUAkkvuMR+W8XrbClNaR8rpkz3R7/9PJL KFYC0r4ywc1tamBOU31oHnbrS/xUfDlH1MRcqysjzbdkG1hBxJ5PhmiCZwARkjEEap8tPeaMh7O0 Izs6JDXzGhO29aIe1XTrzBU7w6LamzquoVZPT9VON/J5Kc39o2t64+MvviVjrclgKxxHbmX03dqt kLFrIyAZ4WcpxrgMSSLwNO9GNWClvNV45Kqe59CEY64YM5R50CPWLHt/ZYv1hCDjC+f+4HvhQ29g Nuy2+eOarHMFION7ow4aKaMmZiPxU9WeeEZzOTqArUnL8cwUuCErYxNKCRKcBlIpvUFuDPHtOtGE GlqkZCShK3tbO48Rkqu03WoKrTpfI8+pP+cjjc2Rlg9F07s6RPVwjdXYjRhmLFPgNDoaWNcVqM2b UvdWMogTVOH0TdBxk1XMtBw1KoWIL0kYSXhVg0iNahlLL5zg09JOPkXnjcLiYibsqvvFiNhK5jKS zwgENvIXRBzQoksZRtZWq+Nf104VPZTV5SdIMDLch0SmUimvvr6+CZBSq7TxJTnxeVdjirKjx/ge 1CBk+58MKWYkgg2i2WPri0eSW6sJ9Sn3ShnhvAkPLxxN3goS1NCyzTAVQq/oiJqW4x7U1fVSJQcS CpWSlGqVQjKAE0Rw+uuApftDWBKu9haMmpfic8TErzsqsnRvZF8n+kZCOHmcclwnJQGlIODQUJ5z GusiqasHin3DIKWkp1BkW08fnhB05LIsbGmMmpZF7bWD1UMrRvxGsdBvG6Plhxq5qZftAF1KaNo+ BVNWgrMX8YdDAjIIgoonqZSlTKWEsu4Iu1lubQjXjVdEi3W1YM+mErEU4TkZvyqr7xwnY/ecdMZC ZASMZIV+CsQJMqz1CP3hVlhAlYtzPLljYZOoMLgH+gbLpULhONE530SiTjDG7QhFNIpM1BE6MrEU e8xrS95hXvNDOF6/5kVgBG69HaCME3H0eKhc5udHjnPt/Fl6Tjjc3i/GiWokSMnR4Tw/3n+Y7+8/ RH0qxezGeq6dP5OL2lvD8g3Tx/h3JEtxJIpmxMkqfHUZ2SKaP34DSU1bX4IEUZgXuyyXy5Xh4eHu fKl4fE//wJRFzc2e3dPXJI6NOxvLXCMyR6zTmVMBI2vUxkBlnZJG2JA3cn8bk7kWjRO5UDWGR9SQ Y/evUnSNBh8VLmKJMG8y17vZ3E+IGhq1lAQS+kpFHj7ZVejq6dmlS6oQEnFCwmc5xhyKUiLx9GCW gayxBtAZcO5+m/GoNOaB1SO9EgQ8PjBMoVJhqFKhI5djTlM9w+UKW7r6AMnsxnqm1ecYLplzMLup nsm5DAcGhikFkp5SiaUtTcggYPfAEBUpOZkv0lGXY0FLIwPFEo9095HyPFrSadpzaX6w7xB3Hj3B D1+4mqzn8409T/C2e7Zw35VrOZ4vUgokw5Uy85sa2NbdR0p4NGd85jTWk/F8Iq+uWrYwa6syoStt 8zWvSyepS7xhugQJRoH7Ug+A4OTJk92P7tv/0x9ks29447w5DXMbG/CceMXhYyVqPmMh/2qCDUNq Ra4b4rGuCyNVMEZUYeJoriotudb5GuNCRiptcoRSd3z9bsRZVKL6JSYIR1s6EsKKBKj3X08pL39z /GRw96HDh3fu3Hk3UNaXzccUnJDwWYqxbUcow8ATNTfnNqNACMfTMSa6EiZXX+pHV6HI3z+0k+Z0 is5CkRn1Of5x5bncefQEX9p1gJQQXNzRxnvPncMvj6hzvie4uL2Nt82fxce27aIlk6ZzuEBHXZZz Ghv4h4d20p7L8Gh3P23ZNF+7dCU3PXGM7zx+kJZMmmJQ4W9XLOS7jx/kf164hvZsFoDXnzON2w4d Z3tPP1/ddYCWTJrBcoW1HRP47r5DtKRTFIOAL160nPach4m+U91MGbephQks8cYFk3gfJeM0wVPC faoCIBgeHh7c/fjj97e0ti7/Qr6w6P87d2FTQ8oPckIEUkrhElDEWmU2/4qNTxshK37nkSZnR9qp LJTIY6xZg75FOAQCquMGELn1CC+YOFwVNpYvbnuKZKuELahVaykDKsBAJRA7unsqP9q154lHd+z4 SV9fXz9K+y0TasLJgD7LMYY5YP3wOSZUnF+GhIzTUjiHY884YzKcPDZPYqES8FjvAP9+yXlMq8tx 3X2PcNexk3zwwR18evUSPCH46MO7ecnUdj7w4A4+vXqpPreLl07r4N7j3dy4egnLW5t5/a/u573n ltjW3cenVi/lfUvm8Ya7HmBn7wAf3rqTe664lHw54PV33s9gsUJ3sURHLtyasM73uaxjAkeG8tzb 2c2NFyxhaWsTl//fZu552SXkKwGv/9UD5CtO1Ks40Zrz5j/TfURfGNLEzrYCu4yWV11kggQuXN4w Js4SUOnt7T15z733fm/JkiUbPjU4eF5rKuVPqa/zpZQeIGR0Yf8zY2sZqZRRePZp41QsRSOMoa7+ fn9CU1NlDHeM3z4YrgSVQ0NDld58vnfHjh13nDhxYj9QRG2eUkb9XRITdIIxasDClfj0YxcJvCFD pc1CWGEz9Bp0tWZpfzanUyxtaSRfCbh4UhtPDA5xPF/ge/sPk/EEbVm1suJ4vsB/7T9E2p6TZD2P lW0tSCT1KR8PwaRsho2TJ9FXKnPF9Ml0F0rU+z6T0hk6gyLLW5uQSCZk0uzqHWRJaxMAfcUSm453 8+Kp7WQ9jxUTmikHAfW+z8RMms5CkWWtTZSDALMvsLCxrqPjKuJTJmu4U1UNZZUuzJeM1QSnBKP9 FlFaVhEoFgqF3i1btty1r7V1T3t7+9zGxsaOSqXiSSmdTXPHhq6urra2trYeIcQZ+4Du3bt3YXt7 +4nm5ub+MRYhdfuDIAiGOzs793V3dx8sFos9wDAwhCLeMqEmbEzSZ2y/JXh6OH0nLM2g0nMNQc6G eo7GC45lSk2wKLM0jGCpkshA0lcq8bPDndT5Ho/29vOeRbNZM7GVt82bgS887j/ZQ2smxZpJrbzV OVfv+6Q8YYNBerpMX6AYUEjqfI9632dafY67jp+kp1jil0dP8v5l83jjnOn8y469vGXuTFKeYG// IA0pnym5LClPOZ6lPcG0+iz3HO+ip1jmzqMn+PB5CwiFDqO5xvqshugf2WxCm/TNXHA496a/k1CU CZ4aAeHLPUAtfcnrzxCQ7unpOdzT09ML5IAs6h3gE1qVT5eIJwKvPXTo0J0osj9T0X7gwIF5wE+B g6eYJ251CFB9X0D19zDQDwzq3wUUCRvhaDRrd4KzAGPzggZLCNJThGoW8StDsxuoA72uF8vQrhOG yhY+f76AlCf4ws4DTMpl6MhmWNbSyF8vn8c/PbKX9lyWmfU5ZjfU8dfL5vNPj+yhI5dlRn2OSdk0 l7S3kfNVDNkLJ7WR9QRrJraClKSAGfU5ptZnedfCWdzw8G6116+AKXVZ3jx3On//0AAffXgXbZk0 vif4/IXLCKS05Tb4Pu9cMIuPbttDU8oHIWhMp6xTlZ0zM6Zks4zBNjG0Q4frH0NHD0vT7vmI/TpB gpowD4gh4SKQJiRfM9ZdksgQJeDTJd864GX6PkPAwNNqwfiiFzgHuAL4IfD4aeQ1WqwRfozgM4jq F0PCRhgyntDmO8FZijEQsIFmm0DP7XrqnDWZikBpvIZ7Y84egX7uQrf90EWjI5vlJxsuAHQkKwRr OyZy2QsnIBE6upVkXccE1m58AYFUpA3wr2uW2hp+dOUiQHLDqkUIBE3pFFefM5X+Upnj+QLvXzqX gXKF4d0VGnwfLyX47AuWUQ4CAinJOBsv/OvqJQD0l8t0Foq8b8lcBstlhnc/QWPKiy6HcHgyXOYQ 9bY0+yVXkaohXhMAIEGCU4BUHlUuCRsiSBGSq3np51EacFp/fELyPVUSFsA7gWZ9PIjaHvNMRReh mnA18B/Ao6eQz9ViK4Qarmt56CfUiPP6unHGCmSyW8NZizGYoEfwHoyETgw1O2OolkGg1ULlwBXf 5cigzvPZMHkCoMJN2nKEM28ce149d13yCKFz3OsZTzCtLscntz9OazrFh5bPt+ZqJKTs4r7qnY0y QjAtl+Wft++lNZPi75YtUOZjHS0n6usZnyu3ZgBcsz32KKxDGM5T1pgzT5CgJgz5llCkWyTqsGxI 2ZifM/q6+egBekp4A7DAOR4ETjyNuo83jhO2PwCuBb4APDBKnjj5SkInqyIh4Q4TmqHNPHAy/5vg dAnYNZFKbWJ2vJqlcGhFk6z16kU5FVlC1BpwbNOG1kyav1g8BxvazoSltBFp7LoIUyU0Y+ljdf9I PWP1znoeL5vWzsumTapyJosuLnBargk2Y/O2hyQfWVpk5oBrlGHbr0lWT4tHylCV1BYBQ+IqGpaU tbdCTJBAwxCwIV8IJT6jFedR5Gs0X1dDPlXy3YAyPbsYQpHYmYpDzm8P1V/vAf4ZuOsp8prB6zpY lVDCTvxjyNmQdoKzGGPSgMM9P+PbjkVjtxp/LGHt0GitUhDnnerAWGaSOaYpG/7VCqW5R5TvamyH Zk3j+jpqydNgpUJbJm2JtxwEHB0uMr1e7QfsKMYjyqqVQOJ7wjEvV7/JpI2gFYTVEUS2NYtc0GEq E803wanCMUObF3tZf7sOQma+NkN07vdUCXghcD0h0RsUObNN0Idix4aE/xLVXz8bJa9r+jdmflfT LRCanQ35llF/smRwn8UY0xxwZMG73tU71GxdDVWqqU6hA+CZvUZrLcOxFBjVjK1G6Zp0ZYySNGkJ 5xUSmYt1SUzPS5cDyeHhPFu7+3j1zMkqkYTuQpkv7T7AR1Ys1PdxjcTRiLFSSobLFe7r6mX95IkR C7Q0xOrU1Gq8bv9FmxmG9ENawcUmT8ZqgqeGIQIDYxo1mpmHIt+8/m3MKqdCwK0ojdD1mnbv0/t0 Kj7OiBMwhOGu/wFFqD8eIa90Pqa/S4RCT4mQlBPyTWAxtjngSFxVbfK1sWBNOodZNPEIUITsOSNd e20FWuM7WSizp38I3xMsb20iLWDfYJ6j+QJZz2P1hFZKMqC3VGZyLstwuUJfuUxTKsX+wWH6S2WW tTZyeLjI0eECDSmPVROayVckD9lQlnW0ZzN0F0o81jfIlRXJvsFBjueLFCoBvzzaRWWZIuh9g0M0 pHxWtraQDyrsGxhmqFxBIlna0sR9J3t5128f4d7LL2JiNm1JUsaI1bY3FnLS6VjnO7wejdWbIMHo 0FowhPOLPqEzVoXQPB3Xfg1GImEf+DrQQY1AWDrfWNfQPhdQa+lRBdXuY/o73r74oHRJ2LU6VJxr JQApI9vHJDhLcXoELLFm1tAMjXNMNRHbjGZ+WEIg4glAwkC5wrf3HeKXx7up8z2uP/ccZtXX8fHt j3NwKE99yufPzj2H6XU57urs4do509k/OMQ9x7u5pL2N9295jOZ0ig8uncund+znWL5IU8rnYysX saNvgC/vfhJfwMXtrVy/aA5pvbb3aL7Ax7c/zrF8gal1WZrTPieKBf5153629wzQlklz3aJzaE6n uP6BHXRkM/SVy7xz3gwe7O4jAPb0DzIx02qbE51b1pp0tVpuj6UciXgTJDg9aM1KCiE8FAH4hCZR Qej1HDc9j6YBvw+4hJDY42lTKFPtmYonnd+GeIeADwA/IDTnjwZ3kwU33rMxSys7VqL5JtA4PQJ2 zKfGSSiM/BRPGIXrrGV2D4mmlQyVK9xxrIv3LpxFRgi2dQ/QVSiR9gS3bjifh3v6+cPN2/nmxcvo KhQJZIV8JaCzUKS/XObAYJ57L7+Iezq7KAWSm9ZfwH0ne/jlsZN8Zud+blx1Lp6AGx55nGvnzACg FEge7u6jMeXz+ctWccfRE3zo4d1s7xng9iMn+NbF57G7f5B/fGQPH14+j0Il4BsXLeOh7n4+/Mge vrh6Mf97uJMXTGwJXb0kcX4lrtmOpPE6HeZ0FrVfeQkSjAKjZel5YfP0+ERN1KdCvgAfBX4BvBa4 BmgnXPsgCM3aZyrM+lwf5fn8BPA6lAPWqa5vdgezS8SQEG+CGjhtDThiUnXmVt19Ns18qTumhfN/ dA45TNCaTvH2udP5zGMHyKU8Lp8yiT39Q/zerCn4QtCaTjNYqShbULmMRFIKKvhqGpqc74GU7B8Y 5g3nTCUtYElLAxlPcDxf5PsHjpD2PCZoU7GUkkJQ4dBQnpdOnUTGg4VN9ZSl5MhwgWIg+c7+w5QD ybzGOnKex4umTCDjCSbnVChK2yXu2KqeoK7Rlypn1ZB0QnIiUcu3dDkj7lmaIMEokI55xQkXOZaH 6U79yQN/CnwJeA0wE+VZfSZHwgL4LvA14G6UgHElyuHsXadZjn4lJISbYHSMORCH9fjVPFu9vZhK JZxfxvmqyjwNIAX5SsD+wWE+tGwuR/NFPvXYAW5YPp/vHThKo++zf3CYFa2NVCTcceQkGzsm8JuT vdT5PhLlwZz1BYubG/j2/sNMyPrs6B2izvdYM6GFa+dOwxOCB7v6yPqK4TKex8yGLN/df4TmtM/2 ngEaUz5Lmhs4v62Jq2ZOprtY4onBPAJBQ8q3hJsSAhlIShVJZ6FIezYTzovX2rtXhmt7R337jaAU J0jwdOGQwpifMCHE64A7pJTXAdcJIS4Acs+Dec23OL+PCSG+Drwd+JCU8sg41SnB8xhjcMLSY0w4 litHpg69eHVy14vYErUM190665YEisw+9dgBJmTS/MmCmZzbUk93scRX9h4kXwn47PnnkhKCqbkM X97zJIUg4K2zp9OSTrFxykSywmNpcyNlKfniridVWMvVS5lVn+MTO/bRns0woz5HSzpFb7HM/MY6 VrY28dXyQb60W5W3cfJEpuWypIXg33YeAOCG81TMgbkNdSAlOc/nookt5HyPBU31PNY7SHt7BqPV 2m0YY++7Wst+bTpZIzBHIkQneA5Bk+1clEkaACnlaMEqzmR8Cvgj4M+B949zXRI8DyHiVhLtuJFB xXmtB5qAtmnTpp175QtWf/3GQC31k2F680v/7+h2gmpnK52nav2vtmlLKanogBW+s66oGASkhUPY QEVKUp5xyDTex/p6oK77fugoJqUkEOAL4cRaDssrBgEZL9qeYhCQqdGGkZypnJtVp44kqW2ylsSV iNBUf0L4/GmlueuWW255LyroQRfQpz8m2Hv5eaCJJHiOQgjxMRQZTZZSdo13fX7XEEJ8G3gVMEtK 2TPe9Unw/EKt5QSjQuq505AaZeQT/6cickibz5QhhHT8i9QuQKpcQUp4mnzD8jOeILrVn9rlSNqy NacFUge30LsghRcQQuLrNCaPLU9KMnqnJrddGXcNcaS98WMzpxtE6mNvL11tGOu6UtVf4QXdb7Fy EiQYX1wN/OJsIF+NT6KUkD8e74okeP7htAnYwBJfgCXPKp8Dh5sMsRl/ECnD39HE2nvfIWv3U6Mm sU/svL0kCKNgyOrruPVyLo9w//Cc3gs4UFspjja3a9ovA2mbKWRckHEu2NOhkJAgwXhBCHEeKv7z D8e7Ls8WpJQPA/+LmuvOjXd9Ejy/cFoELNFTwNZ8HPVyVspi4CRydDtHcwaXwGUYNSqi7SlysxGh AIEqu1xRnsu6oEgdS0GFXf2DlizLQYVDQ8OWKKvaVHXeJegAoc3eqh6BbZ9br4gJ2SVM1wKgtW5D uPF+IZbFfAuBQ+oJAScYV1yNWqrz/8a7Is8yPo4KQPKH412RBM8vnBYBqyndQJlKA6MRSruuN6qh xjQ6M0crZUTzi5p8ndyalEKNVO80LAU9xTJf2nvQIc5QGz2ZL/BXW3fzUM8AIOktlvjy3oNh3WIq bjQMkDTqfCgcGA0Xc//aJuEqIkVp3FIa07I0NXWOa30IzdW6zMAtO0GC8cPVwK+klJ3jXZFnE1LK u4F7gfcJIZIdURI8YzgtL2hlqdVuVkJ7+0qB9KKaLYTOWIYzwuWHIRVZohKqHHB2LYrZcstBwL7B YTqLJYqB5FfHuylXJE8MDXM0X2BSLkOd7xEEcFdnD3/z8B7+6+KlDJUr/PxYN3+/VDJQKrO1Z4CM 59GeTTOzLse+oWECCV3FElPrMpwslCgHklVtTaQ8waGhAgcG89T7PitaG0l5wtFydf2lswmFnn8O m6vaqXToqAnbRWhx1o5/exQAACAASURBVP1iLOaB1pir5qITJHj2IIRYAiwG/m286zJO+DhwEyoI yXfHuS4JnicYw3aEOviNFPaMCPShw5pxL2eznZ/aojBGJHYOVsMyjtYVpeTocIF/3vkER/NFpuay NKZSHC8U+eTOAxwZLrCgqR6A6xbMZFI2TWsmxU2HTvDCyW3U+R6liuSh7gH+8dF9tKZTdOQyfHjZ HD766H6m5TJs7xtkel2WUiA5USxx/YKZLGlu4LO7nmR736AKRzl/BhdOaHbqGBKuNctrw7QjSuj+ MDq0G5IkJGKTWnGvxNm1AevMJsY8ZZ8gwdPF1ShT1kgbEjzfcQuwHbU7UkLACZ4RnP4bXZOloRlh TKp23haHUB2npgjFxM/HnJwiGiYUK5KHewdo8H3++6JlvGLqRI4MF3iou598JeD7Fy1j7cQW7jjW hS8Ecxrq+MjSOXxt32GeGMzjC0FZBvSVy7x/0SzeNmcqdx7vZqhUYVvvAFfP7OAzKxfwq84ePrNq AR9cNIsbduzn0b5B7jjWxQ3L5vLqaZP42I79lkjD+jqmY9ACSvUccHX7YyZ7nU5Yz2ep9zLW5UVv kyDBs42rgXuklEfHuyLjAR3A5BPACiHEFeNdnwTPD4wtEpYEaQJNEAbXUN+B4onAU/Ornpn7ValN qloOTLFbKEJCUAoqHB4ucvnkNrJCsKixnnwQsHdgmLfPnkrGE8xpzFHne5SDgJPFIh3ZDG+aNZnP 7j6IAMoVyYHBPPd19UVuWed5LGtq4Gi+iABywsNHsHdgmMPDeYqB5HtPHFPhKBvqbOWqAmbgttNp n7nqtN8xwoPxnBZhm23J2hQd65UECZ5VCCEWAsuB68a7LuOM76ECkHwA5RmdIMHTwhi3I0SHYQ/N 0NoTCzv7ayNBOet59d7B1atpRPVuSsZ0KyRpTzCzLsN/PXmclrTPI31DNKZ8ZtZn+Z9Dyh/k1yd7 aUqlEBJSQtCQ8njFlIn8x/6jdBVL9JZL/OeBo3zqvPl0FUtsPtlLV7FEU9on5ZBcoLXVet9jSVMD q1obuWp6O93FMoeHC0TI061vLBJndRvN3K4xV8sa/eSYs2PxPawzVxIOOsGzj6tRT+L/jHdFxhNS yrIQ4lPAZ4QQF0spN413nRKc2Xiak4oxEyrKZOqaaKU1wSr+lTZQhoKZOq4ONBGaajOeYEVLAwOV Cl96/DA/P97NSye3cdGEJrpLJb687xC/ON7N8uZ6sp7kognNCAkd2TRfPn8ha9qaaEqleO20SXx6 9xN8/+BxVrQ2cmAwz5q2ZgSQ8WBNWxOekDSlfda2tzKtLqPCUe45yLefOMqLO1qJkKR01zdHP0IY Ug5tx7b9EQ9vExXMMTW7vaC9u+PdnSDBs4irgU1Sylqb1p9t+HfgJPDB8a5IgjMfpxWK8oo1F3z9 k4Uj2BjONvZzNESkKsj+FztpND8nhKQJiaUqEKtPtIRCJSDje4DkSL7Ijw+dZFlLPTv6hmnNpLhm RrtpR80GVwKpomzpupt08RjWbp2LQUDGF5Y03XpVaeyhDToUPMwJO6dbI3xllfARGhuM4foEKf7M n5iEokzwrEEIMRfYC/y5lPJfxrs+zwUIIT4E/AOwTEr56DhXJ8EZjDFqwHp9bCAj58Lv+G+ptcVw BtQNIWlMstbb13VekiEZSYmK1axJ30dwX3cfn9tzmId7B3j99ElOQJBoOeZ+bohLq6FW24sjTmIZ T5jlwbY9tdY9G81frVl2ypBggnfYwmups44Tmms5EAGht3WCBM8urtbfZ7X5OYbPAUOoueAECcaM McwBuz/0khoh9TKjMEE0RpY6HzU8y7AMY7MFbEExzTTUkMOp1I5shm+uPjeSLupZHN4/VIij5YXp nflsqNKM4/cHlCndE2GISekkDEJHLGm/Y813yg/vF2ijgPYv18psGMAjQYJnFVcDv5VSHhjvijxX IKXsEkJ8FfhjIcTfSimfHO86JTgzMQYNWGuA5n+9+UB4LZKsVtYqDdBoxMIx2ZoQlcpqKyMFhiEv R4sRHauvs7wncKNLaURCSxKmCzk1en9h2hCZ0w6wmryZC3cJ33yCWvWN9p2aKw6q+ipBgmcLQohZ wBrgR+Ndl+cgPq2//2Jca5HgjMYYdkMK5yZtbCc9tykcu2vVZgVxL6s4GZv0hOdCUnTyucQcsfPG KljzE0TKIZCR+gYyWq6IrMWN3z8UOqzp2W1XpI3V9QxjUGsBIZDIINDkrMJ3RsSOhIcTPPsw5uez ZvOFU4XWer8DvF0IMXG865PgzEQtApaxD4AUIrI9T7XmKZ15S+3lC8o5yawTtuQa11xdYnEmTsN/ 5rSJxGVVyUi+WtsAVnOwRAQ6frWIXhMShBUYnHvK+P2Nx3KsqyLtqN2pan5YxjRie7GKZ8N42VEN PUGCZwFXAVuklI+Pd0Weo/gkylH1veNdkQRnJsYQCSuqyUWjSrrbDATqY4jWOifpkIzCLD8amdCj WrIbEUqG93LJPEaIIvYJNUsZEq5zvppB42QfI85R+scuH4pJAKaedpcjGZYvcRzVdDtt+0a5ZYIE zzSEENOBi0m03xEhpdwB/AT4EyFEw3jXJ8GZh1MlYGsFzRunKksommTNdns4WpsEZ8PgWL4wfZRZ olRTtcuQXXhLFbnFCTj+LyzeEF4QnndyROoQtweEbtYqR+B8Rlr94zZJt0UGMRO02w/uQaSfA7dE g/hNE55O8EzgdagnPSHg0fEJYCLwjvGuSIIzD09FwJZ6SqVSuVipdO3zMtWhrMykMFGN1NVoFe85 TkVVxBIlNHM9rilXq4Ij2HpH+pxqOkvUsQyxciwf65OhwBB1ElPWgCjhuhq89cE2mnOUtVVZgcRX J0f6uyXkm+CZwtXANinlrvGuyHMZUsrNwK+APxdCpMe7PgnOLIxGwK4+JoeHhwePdnf/aqtXV6mg HIbctakyiJpbzdyvTVHFZTGt1bX44hC5IWSdxnXqCjVjl/CfimlrNbM6vXsPVwNX65+D6vtJqZ26 4rc05u0oQuIO26t/6P4MrQrqI8jjSZ9KJZfLeU/RqAQJxgwhxGTgMhLt91TxcWAm8KbxrkiCMwuj aVIuAQfFYrFwvKdv96Ok+g6LjAy0jdloq3YZb9zsawk5nNsMHZocRdPO6yrTcHUtjKaonbpGmVOO zDnHNXFnftZ1tqo2jYcihCB23jQkkNbCHjd/xzXdaMhKWVVP20Y9b67aY+ok6PMED/j15fzA0IF8 Pl8gnLiO91SCBE8Xr0O9GxICPgVIKW8DtgJ/KUYKwZcgQQ2MFojDvODLQFAoFPKP79+/o72t+b7v Nbesu7LcXzdJVkgLGdHkwsdPRE9ITUMivCyk9usVUW0wLKzGgRSxY0NeAJ6NbiV1GmvaDdwbOXsy SbeaUokJpq61KiOdYyeJxA9TaUXYuZ2tUTh/XCMcpQApvUi5ZU9SwGOHn6v8QOYOP/TolpuBCurv 4toNEgJO8EzhamBHEmbxtPBx1G5Jr0I5ZiVI8JSoigUNIITIoOJB54AGoBloAdqbGxrOWb36gje2 5nKzzpf5hjYZpNNCKk1ax3+Wsjaf6sLVt5TVgZ6jdYgcm1rGc4x0/plGvJdq0Gf0vNuv7m+7a1Q1 bM9ZfhZyQIpKpxSFByqpE08+8cSvduzZsxkVB/ok0AMMAIOoWNAlVCzohIwTjAlCiEnAUeBjUsoP jXd9zhQIIXxgF3BMSnnJeNcnwZmBkQg4DaRRBFyH2pChBeXtN8HzvIkzp09fOKW5cU5bXd0kD5GV 4Cv1DWSoej5tGBt5EDseCSOlO9X8Y0n/jO18YIwEyqYeIINKvlIeODYwfOTJY8d29vf3HwW6gU79 3Ysi4CEgD5SklOVnqjoJzj4IId4BfAVYIaV8eLzrcyZBCPFu4AvAeinlXeNdnwTPfYxEwD6KgLOo heb1KC24DWhFkXELSjuuR5F0SueJ+xdR4zhBiPgfwPB5GaXR5lHabT9q16Ne1C5IXUS13zxK+608 C3VO8DyFEOJnwBwp5cLxrsuZBiFEDtgPPCilvGKcq5PgDMBIc8BmbrGCNmuiXvBDKJI1+cz1IrUJ OCHeU4dLxBVU/xcJyXWIKOEWCf82lRplJEhwWhBCTAA2Av883nU5EyGlzAshPgN8TAixQkq5dbzr lOC5jdEIWBI6+xRR1ti0/hbONaOhpfTHd8pJCPj04LpQl/WngOpfQ8DG5FwgJODaa50SJDg9vBo1 hhPv57HjC8AHUVsVJsuSEoyKkUzQAkW0Rqs1Dll1KJNzo/6d05+MTuejSHeM+wwnIBR8JKF1oUCo BQ/qbzPvW9SfClBJHLASjBVCiFuBxVLKueNdlzMZQohPoHZJWiCl3Dfe9Unw3EVNAgYQQhgCNppv BjUnnCNKvFmi5mejASfa7+nDXXtd0R9jai4QErGxOhiCNuSbaMEJxgwhxDDwWSllstH804AQYiqw D/ialPKPx7s+CZ67GI2AzVyuIeEMilyz+pPR1zL6uk9o0q7liJXgqRGP5GHM/MYhy2jDhpRLhPPF QULAZzZiQRzGY/ysBx5EOfw9W7AvoGfbevM77u8vAX8AzEatWniuYNz6O0E1RiRgsFqw0WqNRmy0 XfNtyNekqfUgJ2Q8Mmr9AdzgGmaO15Ct0XhLhI5yKhZXMqDOKDhCLvrb27hxY0c6nQ5+9rOfnQC8 DRs2tKfT6eCOO+44AYjn0XEnIDZu3Niu29tJPPbdM/w8x/rbe8lLXtLheZ7UfS02bNjQ8Qy2dT5w f0tLy1t6e3tveg70PU5fnyAq6P9O+jvBU2NUAoYICRuidU3TvvMtYp8EY4erAUOoCQdUR8FKyPcM g0MEAvAmT56cufDC8xcuWSK79+3LvN7zxODq1cM3nzhBw969uVcJwdDy5QM39/V59fv3179SCG9o +fLizX19on7//vQrhWBo+ZrizfkeUb9rlzpes6Z4c0/k2Lu5p0fW79oln6HjePnFm4/3iPr9+jis n//KeP09TwyuXDl488BAqm737syrgIEVKwb/+9ZbtxY9b3Hu7rvv7sERQp/usx3r79TGjRsnzZgB pVLzG0AOX3xx8abjx2XDrl2ZV3ueGFy2rP+WaF/33dzXV3faff3II4XXZLOZ/t95X68p3tx3vHZf C8HQqlVDN4V9LQc3biz++OGHu4u7d+eab7/9rsNE92NN3iXPIkYLRQmAlDLQD7Ab1jggJGXzbRyv EvJ9ZuBuUGwGiHHOioSgTAbMmYOYQOu9970TsitXrr9g3z7vo695TfPNv/1t/sp0WuTXrZveMTDk 1f1m08Cl6bSfX7duXvvQkMxt2tx/aSbt59evb2kfHAxymzb1XZpOe/n16ye1Dw6S27Tp5KXptJ9f v769fXCwktu06YS+Plkdbz55aSbr5Tesm9Te309u8+bOS7NZL79u3eT2/v6yc9ze3t9fym3afPLS dMqUX8pt2tR1aTqNU36nc1zU1738+vXN7QODldzmTX2XptLk161d0D40VMht2jR0aTpdyW/YMLO9 f7CS23xv/2WplDe4du3k1MUXT+v81rf6WoJg0nd//esTRfRzL4SQY51ecft72rRp6Ze/fMmic85p e+WLX1x/8qGHeEU6LcsbNjS29w+Kus33DlyWTqfy69bN7hgaErlNm/ovTWdEft36Be3DgxV1XNXX Xn79+o5YX7e3Dw7K3PTpJy/N5ExfB7nNm0+O0NeT2/v7C6qv015+/bpJsfImOseyRl+36r+NehbW rm1qHxoq5TZtGrg0nQ7y69bNVM/OpsFL02k5vG5dtmXFiul9P/nJwPylS1/57//yLzfv1c+j7W+S 98qzgqfUgCOJo5JkRIqvlfyZqOBZCFnj2/1tN2BIBsiZhfiUzpVXzqr7279df9m06Y1/MtDvvXjy lIwn8FU0tIhRyQNP4Fk51zmv04ZD050F8vC8uFzsftcYom58cxtTVsl6gQRP6A1GAndrzcDue6Y2 DqvocKtKbpQAsqI3ZzHn1G/1reTK4Xy5dNtPe7c1Nw9/4JprfrSZcI27sfKcFgnH+/uf/unF0+bN m/qB+fMbXjVrVm6K6rOwv80WLOAhPIGIuLR4IAQCD1WsiSgf/j2E5zvdJ3S03fBvMVpf607SB5XI hSCIDPuwX3UeKV0F9hT6m4ByqSKfOFjo7Dw2/L2HH971r3/1V5tPEF3SmFjWngU8pQbsQob778Xn U1wkxPvMIP7gq3GVDIgzEjEy8KdPn16/fPl569rbG/6uoT69qqHeC+O3SoEUersQk016IJyXuDDp 3UUHvrMrmSJlKYVD6JEamXqp9JFNTdwU6Huo6KjGAGaGv5SBJqHA7kqG9JAiUBunCB8hK6o+VJCR 4LJ6ZzF8pCxTl0ulX/GK1mWDQ/Uf+MhHLnzP3/3db44R+j5UhBDeqZJwvL9f9apFbRs3Tr18+vTm t+Ry6Zxqqu5x099C2H4Sbr8KT7dRFanMgAIhfB263fyNsH839bdwN10Ro/Z1FObegaqjCABPE234 NxciCPeN0X9n8CGoECq04WtadYn6u6RSQsydnemYOd1/a2PjvM5Vq3q/vWXLjm7d39gKJMF9fqc4 LQJ24ZJxggQJRoaIqkE+kD7vvI7Jra1Nf9PXx6rWVo+IPKtf7Aj1sveEyYpKI/zwZS9AOC9Z9W73 8Dx9Tkjc2DghL0Xl5Op9UZRmGyXkcM8Vs2WoEJ5Op7VCrWUpTvCU1iXNDJanSUlXVHhKW0bactJp kWmoT79g+vRZb4TffCFSIUXC4qmEUKe/fcCfNm1aw4wZc9c2tdRdl8v5OWJ9pghW3UHJOD6R/pFo 4cKQnNaIpSZx4Tn959n2G41ZacKh8FR7DxqjybrwEARIocg97GtVBxV6P1DCgqho60NYhtDCg9Tb weJeESq/ELI5V1f3rtmzJx/csmXHLU5fS92VT9nfCcaOMRNwggQJThmuE2MKSM+b5/m/d01jf3NT GsB5aTuvfmm0Jk2gwsNsx6nCtRuTKY5GHDNRW7cNrbE6JBqtnnR+qxoh/ZAwCfeqRpOOMoNqM6yr 7UlTUoC0pCuNCQfpkoE09QxsOwqFoOHAAa4CvkbUW9f1fRgN1uwMpCdMqG/JZuuuFNJfGDHBa41X On0Y7QPXRJ3CErfViI2QQ/gbwmtSICPkXKuapsOE/puGeo0SZvTfWMjQ2iCk6leTzghAIkDo7UxD otZShSFnLQxpDsf3hWhrTbVMnd6wABXbwaDgVC4h4N8RkohVCRI8O3AJODs0VGwcGhJzEGb+1vXN QpGD57IxRr21nKoVI6w2JkOiDTOqcoXwlaZmSVutHFTnfRAp/dFzncLX88dCE5Se/8TMe3qKzIX1 BLSamSoDpw5GY9Tzq64pV2uV0hYEuTpPbtzYWEFF2zOBfgyhniqEzpdKp0+UX/jC4J729rRvOs3c z4oNmiWDSPbQdCsckpVStVfqdKHg4/Z12N+GyON9rX4bDdolf2de2faVZ/82ru0xZEYRpcmq3/qv GPMVEMKjsSlVWX1+8Und3ybeQ8wMkOB3gYSAEyT4HUJE33hml7HM7t2F+s2b8m0hCQiriBrFRZ2P OmMJ/cJGCkf7dF7i2iwtDUPjac3K1ghjgnR9Ks1xONfp2bwhibhkYQjZwzN1ckg3qhRGXzOKeL0I Gdh2AZ4nRUeH71Md5tbTXTqyThlKM6a/M6VSXf3Bg8Fsc/N42yN94NZVE6+U2qFK1U7n920bpPSM YYKQPMP+FsKv0Vb3sXD6WvhOPrevQ0qOntf/BPbvb4javZ8RMKyMhNDWCKiUg/SBA6n5hARstqMV gDdafyd4ekhM0AkS/O7hEkIayHR2lut27izWAYRvd6XllIoVHt/Xy4L5kxAp6XjSGn3NaMnqP4Ga D/ac26kXbOi4JYFSsUI2m2JoqMCuXcdYuXIW0b1TTLHRuUghBMViwK5dh0mllAk0qAQID+bNnYTv K/OncQQS0rOORgLtkGXmMxEIaZT50CztNIhSUYgt/z977x3nV1Xn/z/P/dTpLZNMegiB0AKEEooQ iqAuqAiIDZWiv1VZXUEQK7qAuta1ICKYVVzFFZayUoKhQwCB0ElISK+TOn3mM592z/n9cc6599zP DNXJDF/3vnyMmc/nc8u5789wXuf1bue5vO0173Z9s3Z8vUQstzlQolhMtaxYkTotEkcf4lT1Apd/ ueyzeXMfpZKOTUupvRET2xppaKgyalSY5zWJZNaVbhdBxnMQ3Rg9/O6klPhl/RjarlqcS6kT3GbO bCaZrOzqmwB8hHAivYGtKxO+THw9WNBVekX84Mr5PNUvvZQ8DbgJ7Xq2nfcShJlcsRt6NyAm4Bgx di/cWc+6oNNtbSJ58sk1vUKIFutPFmjX5q6OQb75jXtZsOB0mpvrnCt52AQtVTGhCuW4irWvEeGo scFckQcffIV3nrQ/Gzd18rWv3cTChZeaZK3K0XohJ+KjlEdnZy9f+crNJJMeyaRHsVimoSHLVVd9 lIaGjFlDCCdGLDS9Bu9LQu70dAYvOkOa4Fh93kBOebff3ldH2PK2QLTT3msRQqXHIV0uky2XaQDH BSuIqF3PLGYUgv7+EgsWLGHlyl0ID/KDZRoaqvjXfz2BefOm62uoilu6ceEgi93GCUKFDVAu+6xa tY0tW7o44IApXHrpjYFdSyWf+voqfnn1x2loMNNzIK+1bbXnAxPPl0YN69i6XvzoMLkw/y+cSwQ5 cEHGtwSQmYzfRdjbP4/+Oy05f2QxdgNiAo4RY/fDVcAmLilTbW1JP9AtJtNWKkGp6LN8+S5yg5Jm M7mjIDdQ5KWXtlH2oboqw0EHT0EIydb2Xtav7ySdSXDA/lPJZFKsXr2Djo4BqqvTzJrVxnPPbeKC C67nuus+zd57T6SxsQbhCQYHizz3/AbKZUltTYaDD55OPl9i2bLN1NRk6OzsY+LEeurqq5g0qYn1 63fy9NPrOOaYvaitzfLCC5uZN28GnidZs2YXTU1ZurtzFIslurr7qa5Ksv/+E/A8wcaNHWzZ0kNN TYr9D2gllbQ8KR2lpqjKIo84oqrw5z8H7lA3BvxGCMFeOAkky+W+wenTc7cBnw+0dlAyZNSijasD nidoaqrC8+Dee1cxe/Z49tm3jcF8kUcfXYvnJWhrq2fGjHGsXdtJsegzOFjmkEOms3FjF1u39dDY UEO5LDnggGnkCyWee249yUSCadPHkU4n+eEP72Tx4hXceeelTJ6s7bpkyVqOPXYfMpkUL764hWOO mUWxUGTp0nZmzx7PypXbSCYTdPf00dJcw+x9xlMqllm+fDv9/QM0N1cze59WvQZQHrjKWIXrFuud COxdLQb32afnfqIb69hFT0zAuxExAceIsftRqcqS27aV0k88MVhz5pnVBHOcSOjUJts8w8aBlSJf 8Fm0aCVf/epdTJnSSC5X5BdXncXMPVr5yU/u429PrAMFF1/yLo49Zm8uvvhG+voK+L7P579wMs8/ t5Hu7kGuuuoefvzjs+ns7CefL3PXwhf58iV/ZOrUFgYGClx11fk0NFTxiU/8imOO2ZsXX9zEvvtN YsGCT3Httefy/PMb+NCHrubaaz9JqVTmAx/4JT/7+YfZa9Y4vv71/+Wcc47k5pufZcuWbkoln/7+ Aj/4wXuZNauF733vQdas6UApxWWXHc8JJ+7hPKSHUBJEgkxGcfwJNQXC2K+bFPR6hFAZXE1IqZK+ LxOWYEPFas1sdaJ+p74+yyWXnMDGjd3Mn/9LPv/5YznzzLn85faX+N53F9HSUsvMmeP47nfP4Ior 7mDTpi5qajIsWHAeV1zxF9as2cHkyc1s3NjBTTd9kQcfXMaVV97G9OmtHHLITD7ykaO4//5lAOzY 0cd1132a557bwIc+9HN+dc25dOzq55xzfs2DD36VrVu7+fSnf8ef/vQZPv3p3zNpciM93YM0NGb5 xc8/xKZNnXzjG7eTTHrU1KT5yU/ez6xZLQihn8r1LNgSKe1u94PQhV8m0dGRmkRIvpVJWDEJ7ybE SVgxYuxeuC7ogIT7+lRq1apiRtmyHEGUEIRWYva9jl05Lrvsbk48cS+u//3ZtLXVc9GFt7B0aTt3 3bWUa371Uc4++wjuvONFOjsHWLduF+effwypdJIFv3mYc8+dT3NzDZdd9gEGBgps2LCLXTsH+PrX /puTTprDH//4BSZObORLX/o9uVyB/v48p5xyCF//+gd47LFV9HTnUUpQLutuV1JCNptmypRmFvzm UTZt6ubll7exz75trFixnWQywTXXfIjW1lq+9KW/8Ohj63joobV89rNHUlef4cILF5o4tZuJbGLV JXjpxcEhyVe8sXa3bmZVAkh4Xqa+vb3mpCD7Wbg+bGWSyBxyNsQlpRaRxWKZ3GCRhx9axYknzuaD HzyERx9dQ3t7NytWbKNcllxyyXtYuqydxYtX8pOffIyjj96bnTt72bKlk4su+iPz5+/Hhz98NLfe +iTt7d28972HUFeX5aij9kapBGXbPAxBU1MNAPff/zLPPruB2ros2WySLVu6mXvwNH784w/yyort XHvdYn784/vo6srx6U8fxfPPb+GXv3wU66auhM1U1xEKz2SCK4olkd24seZ4wp3twpTumHx3K2IC jhFj96OShBOtrR7vfGd1f5iRaqs69ZwnpaK3r0A+XyKfL1EsSkolyZlnHkRTYxWHHz6NXbsG2Lyl m1QqwQEHTOaDHzyUCy44gXzeJ5tN8cc/PsHmTZ14nkddXTXJpMekSeOCyblclpRKPmeddTRNTXXM m7cX3d0DgEdNTZYPfGAec+fOQElJPl8aoocam2r4whdO5N57X+bGG59mzz1bqavNkEh4nHLK/kyb 3sjJ79qb/v4i69d1MjBQ5K6FK0DBpEn1SKkvZmPflhwGctK7667+GqIbvrwR8nXtHShhKb2k74u6 YJGjnLw3Q1ZKPLq5mAAAIABJREFUeUE9sAhc0/piSkHC86ivr+KZZzZx110vmcxihecJzv74URx1 1Cy2bO4imUyw336Tecc7ZgPg+zrmu3LlVu6/fymTJzeTy5WYOrWVqqoM6XTaEKEdjUdDQzXvec9B XH31/dx669N84uNH43ketbVZzj77SKZMaWb8+HpWvrKDzZu7yeVKLFz4MgcdNIlMNnRqChO6qPwr tGVjQeY9yHS63E10VzuXgGMS3k2IXdAxYowOXNeoyGQQE9qS5SBRx0mWEUAuV+LWW5Yye/Z4PM+j bWI9s2e3cu21j1Ms+jz55AaOPnoP9pndRiqV4O67l/HYY2t44YXNnHHGYfT05PjOd87kF7+4l1JJ Z7yWy5KnnlrFHnu0AVBVlWGffSZzzTWLKBZ9nnhiFYcfPitsHGE947ZsRjkzOB7pVIJ99plIJpPk llue5frrz8Ge/Je/vMjMmc3cvXAFhx8+lVmzxjF+fA0f/ejBbFjfSTpt+y2bpCEhwLRarK5KyCOO qC7ceOMQFfZGyde1t/D9gVxbW99dAvGp4AGco6zNAw+E9vsH3JVMJujty3PXXUu56KKTSGeSfOfK hRTyPolEgmwmSSab5sADp9HUVM0ttzzDmjXbAUEmm2Lu3D047rj9OOywWTz00DLmzduLDRt2USyW 2bKlk7a2BqfhiaCuroqzzjqCq6++l7a2Bq77zfn09w3Q35/n+usfZ+7cqWzc2MHHP344Dzy4kr7e QT7xiXk8/fQGTjppr+A7C1tXyqDUTYkw/g0KoZJk0uXCjBldix2buenXMfnuRsQEHCPG6EIAoqPD 95Y8la+aNtVkOSuFErC1vZ+duwbwPMG11z2FAGpq0nzkI3P5+McP49JL72DJko2MG1fDJZecTD5f prW1ls9//r9pbKzmG984FeElKBZ9PvOZ6xFCsMceraxZs51UKsEVV9zG5ZefRTabYdu2Xs499wQu vPB3PPHEKlpb67n44vexbt1Ostk0S5duYvu2Hqqq0qxZs52dO3vZsGEXNTUZVq3ejpQ+2aoMxxyz F88/v4np05vZvKkL35d0dw/yb5ffjV+WXHjhfGprU9Q3VPHZz9xKQ0OWSy45loGBIrU1qeD5tetX kk7D8cdX53FIlDdPwpEfFba7wmQpBX5vz9zeEnGp7LN6VSft7X3U1WXo7h5kw4ZOJk5s4PLLdbfG xsZqXnhhM/X1WXZ1DLDylW20tNRy9NF78Yc/PMr48fUIAeNbG/jwh4/iyitvZcGC+5kxYzwf+9hx ZLNpBgeL/Od/PsBppx3GuvUdVFdnWL16GwAtLTXU1GSYPmMchXyJLVu6KRZ9/va3NSxc+CItLbXM PWQaU6Y08dnP/olPf/pPtIyr4fjj9ySfL5HNJgzJosvRnA0e3NIvk/jn9fdnWogJd9TxpnZDihEj xpuD0J0VMuia1hqgAWicNm3ivh/+8HG/+upXJyV1WY72+t1888vk8z5Lnm5naA1p6J72vLDeFML4 oVaVw3OWiEjb6OdKaXfq0BbvquI9/W8y6bH//hM5/PA9+PKXb2L69GZOOWU/li3bygMPvMI558yj qamKRYuWm3OUuRYIoaity3DOJw9mr72bCXfs8VFKUciX5X33d2w+55M3XAjsArqAXmAAGAQKSil3 yyDX3ilj72pr7ylTJs487bQjf3j5FdP3DBqXkMTuZmSbalibdHbmueLK+/SeBhX2C3c4EhH7V1dn mT9/Nrfe9gwnvfMANm7q4Im/reZ3v7uAb33rf4LvKGzCEdZCu7bV4YQp1NZm+PrXb+SnP/04ucE8 a1Zv5/rrH+Xee7/Ek0+u5eGHXwnOUyiUVAihaGjI8LnPvYNJk+uMXZW2rVIoys57yrS6lHR3leTF F6/b/Je/3PklYAfQA3Q79i4ppdxNGmKMEGIFHCPGGGD8+IR85zur+4FGLci0IjviiCn4EvbffwLR 3CPjpg5aFkZbWEZJwQ3huceauGBFL2Pd7cleV0/QtpZUk0S43Z3uJ6wn+0wmwQsvbKKtrYHvfe8M isVBpk9vxvNg+oxm9prVSltbHSHJaJIFSCUFbW31gVtUycBJykBOeQvv6qt+DfO9KZWmlEpK6dUE CxolTKKb7RylnExoqK1Lc84nD3Ns4trYtqVMOLYWJJMJGhtrefrp9fzXHx6lqbGGK674EA0NNXzq UycwNKQqdKaycslQ4QmFlD4///ndnHzyHE459UC2tncxfXoLy5e3U1Wd4aijZjJzZkvwHdkaYCV9 UimPpqYqYyWt9EPntrG1DgIHhlQomU6XuoexcayGdzNiAo4RYwyQzQrV1pYqm3AjthHHtGkNgMce M2wLSSd0bIjT7bYYbMpgyUTZpv5eQBBue0N9jYRD5C65GEVl9ucN9pBVCow6DQnaRyE54IDJfOxj 8zSJqWomT2li7iFTA1U7aVJdQNpS+di9f0NlZjdhsMwgqK7y5BFHVOdvvHFkbO37ub4JE/oWKqXO t3bWHayCrhS43RbTqQRz504JWkgG+/7ahUvQDtS1rfZiXHHFmcHvdoOMww6bFbF32IbS2rts/lXG 9pI//OECbMuwqVPHMXVqI0cd+f+ZeHkNU6c2afshnb2Z/cDWwcYZjodTuaRrv28lyGYozJjRubjC bJWukBi7AXEWdIwYuxfDqoiODl889dRglZOJChA2+hfO3GdqZGxmrlKKvr48q1btBEAqn+3be1j+ 8tZgki2VyqxcuQ3f953LaIWpic932kFK8vmiIQCtxJTSqjQMUZn5uCIxy35aLJaRvs9Af4FlS9ud J7XBV2X6FQepTjoxyChQ152aTivmH1dVYEShhM1u1pBIx9Yq0t1Sj8kOtZAv8+xzm4IxDvQXeHlZ O4ODRUBnOW/a1EFPz0D4jMJuARi63u3zhbZWSFU237mzGMF+5eZ7Fypia+lLiqUy+XyJZ5/ZGFgu tLX5WzGPoj+VkZ7QmPovhcT3ldffn20ZASPHeJOICThGjNFBxKU3MKASq1YVM5UTpz7S9Eu2E7hD ggqTIX3bC9x449MA9PUV+fWvH+ErX7mFDRt0o4tdu/r55jdvprd3MJjYVbA3rxmO0O91d/Vx773P EbqarUs8mPJDKWRJ26grAQwOFnjg/uWsW9fBpk3dXHzxrfQPFNBJVdEYsnKyfS0xa163iwwolWHZ 0mLq77K2g2Sypnrnztr5AVEJnXoVKGETPw9hlamiVCqz5OkNfPMbd4KCQqHM4sWruOiim3jggeUo pejpGeRnP7+Hp5asI9iTNyI+recABnN57rnnOQqFPHovX3tEqIjt92wGESyMBOD7klde2c7iR1ay q6OPSy65lXVrdwV3ce/pqvrwN6uCRfB+qSQy7e31R1eYLXZBjwJiF3SMGGOA1lYdA1ZKNgoSKFGx H7BAu3/NbkSWoJRUtLf38L3v3sPdd18AKHbu6ONHP7qH2toM1//+cS7/t9MpFEsseWotL720Cc/z aGmpZ999p1AqFXjuuU2USmXq6mqYNWsit9zyBN/5zi3MnDmelpZaNm3uwBOw114T6OrKsXbtVpJJ jz33HE9raw2dnf0sW7aZRFIwbVqj6dz0O84//2j++Z+Pob+/wL33LOf00w8MOMWqbWFI2bxrFLf+ 3b6dG1DewoWvGQN+MxBKqYTvi1qdaW4WN8JsZG/3LDZZ6AIiLuKurkGuu/ZxTjttDkIIenpy/OQn 9/HUU+vJ5Ur80ylzGBwssuivS2lsqCabSVFdneXAA3XP6FWrdtDR0Uc6nWL//aeyZMk6PvvZa1mw 4HMcd9x+LFu2ierqNLW1Gerrq3jhhfV4nmLixEZmzmxlcLDAiy9uolQq0tpaR0NjFT/68SIeXbya u+66gKOO2oP/+I/7+eUvzwoeWDm2tAsm/R1EPQ0h5yuZTvuVMeAYo4CYgGPEGB1EYmpVVUK2taXK gUpRbo0mCOUmXJl6TiUolXxWrtxJNptijz1ayBdKLFvWTl1dhj33HM+Nf17CN77xfgSK3t48P/zh XfT0DNLYWMPVV5/Lxo1dnHvuNUya1ERdXZYf//iTLFhwP/39ef70p8XMmDGen/70TmbMaOX73/8o v/3tgzz88HKSSY/3vW8uX/jCyVx//WIWLHiYceNqecc7ZnHoodMpFn0efngVn/vcfD7y0UP53vfu 4fTTDzAPrtWYRGC6b+j3lXHzRkOVZKs8ecQR2RGNAbe19S0UgvMcn2xAQM7+DJGPpFJ0deVYsmQj P/3pGUjps2tXH88+u5GDD57K1q09bG3vIZFIUlOT5uabl7Bo0VIGBgr87GefYM8927joS/9FV+cA yaTHv/3bWdxzz4t0d+f4+S8WMnFSEx/5yE85+OAZnHrqXNLpJFdeeSvjxtUyc+Z4fv7zs7n//mV8 85u30Dq+jnEttVxyybt48IEVAGze3MUZZx7Mx8++nsHBEtms/nvRyVY6Kcu4UvT7JndAKhl6MlBk shRmzOiIY8BjgNgFHSPGGMDGgEO3qHVHWjaKzn1K2Vhtieef30xVVQohoK83z+9+9zdmzmzlsm+d SrFYZvWqrYAuFZo7dzo//vFHWLp0E9f95gEef/wVisUy559/AnV1VXR3D/CVr76fhoYqPvWpE9i+ vYtdu3o5/fTDqapKsmjRi5x99tHMm7cn11+/mG3buvjpTxfxzW++l299+zQ2b+5i333bmDChjpNO 2oeJk+o5Yt50crki0pCtdnda4g0TsGxZD9i4qRsDrhmpGLC5QxjzpiKmGrj6A5c/JrlJK+BEQtDc XMVgvsTixatoaanlO985jVyuyG23Paev7kvGj6/n2mvPpbGxhi9+8Q/s2NHNqpVbOffc+Rx00HRW rNjCuecdR3NzDd/8xhnkB/N0dQ0wa1Yb73jHbB58cBknnbQ/H/zgPB599BVWrGjnK1+5icMOm8FV V51NIiEYGChwyilzqK3NcPTRM2lursH3JZ1dA5GQQRCvr6BQ68q2md8ohfSJY8BjhJiAY8QYHQwf A7ZlInbSB8JMYycWaGN3QpAwW9cpJeno6OOhh1ZSKvss+usySqUyf/jD31BKUVOb4aMfPZLJk5to aKhm3dodHHLodOrqsvz2tw+yatU2isUSEyY04HmCxkbt9W1qquX88+eTSnlMmdLM7bc/y0MP6Xhn brBINpvixBP3Zd7h0/n8F06gri5DfX2WKVObook/Kjp64SRxKefzYLmhM78olxTLlhZGMAacrd65 s36+voXNEo6ODOWOVwaS3N2Kvqc7x4IFfyOZ9HjgAe0VuPHGJRSLRRIJj1NPPZCpU5s58cR9KBbL 1NRmaG2t44YbHuW++15CCKirzZJMJpg8uQmAlpZavvvds2htraGhoYqnn17HnXc+pz0GUseg3/e+ g5g1azwXXXQys/cZz9SpTVRVp0mnk6Fql6GqtUse4Wh6/T9pU8Ii+jaOAY8dYgKOEWMMoGPAVf3B JgDCmfGErVOVoYgxGczCU9TWpEkkBIP5Mk88sZ7GxirOOP1g2trqmTt3Grfe+izFUon+vgLXXfcg jz++il27+njPew5k+7YeTj55DuedN5+NG3fx178+jycE+XyJJUtWk0wK6uuzSOmzc2cfL7+8mYsu ejfvfe9BeJ7+rKWlhltueYb/+Z8lXPrlmymVfaqr06xds5OBXJGe7kH9kAJCVRn1MwdkbGPfRiHb /YAXLuwfwRiwp2PAuPFd6SwIlMk0dgSj8Y0nU3p0xaLPtm19bN7cxfvffyANDVWcfvpctm3rYfOW LhIJj9tue5aHH17BE0+s4aCDp9LV2c+MGa185jMn0thYzV/+8jRKScplnyefXEXYS0TS05Pjjjue 5bzzjuXss4827nnF3nu3ccstz3DH7c9x3nm/Y9PGTjxPUCyU2byli1KpjBCCbDbhLHxs4w03EBwm +wV/b2FWuu0FHWOUEceAY8QYHQyJAU9oS5SVjUG6uyIpQveskLr2VEkUgnRKsPferezcOcD27X08 9tgapk1r4tRTD8D3FXvsMY7vfnchLzy/mVQqwU03LeGmm5Ywfnw9e+01npde2sxNNz3BTTc9wYQJ DRxz7N7s2NFFqeRz6aU3cNpph1Jbm2Xp0s3s6uihVPL5zGd+B0Brax0b1u/k6KNn8b3v3Ul1dYaz zjqU9i2dTJ3axKJFL/Oe9+zLokUvM2VKI+WyJJXSYwfbm9gYozIhyGZ9B/sBj3wMGDjP3lEo3fZS NylRQXZ4WKWjCTCZ8Kiry/Lii1vYsqWXiZPq+ejHDiXhJdm+o5dFi5ax6K9LyWZTvPLKNj772d/T 3FzDD374YTo7+3nkkRU88sgKamuznHnm4axes5VUKsGVV97CZZedTjabYunSzXR355g0qZFvf/tW QLe6XLVqG2eddRjf/vb/8thjq9hnnzYSyQTZbJLBwRJ/+K8nmTOnjebmatOrO8yfjjbpsKbWi4qg +Yexdzrjx3XAY4S4FWWMGLsRQogkepu3SCvKffedNPuii9758zPObKkJW0d66MMJmjjojku2ZCZB Pl9m0V9Xcf31T3HOOfOors5y511LcSo/cYp10cQHnusbBqel4mshzJ61jTqsqzho6uDUK6fTCWbM aOK3v32Cyy47mfnH7Ulzc9YsHqxbV5qrSKJtEW3zDx+/rOSmTT3rDjvs919m+FaURWW7Vwy195BW lG1t9RM/+9nDzvqXz885z3O6h9mmJFYORpptIMjnfR5ZvI6nntzMlvYevnzJO/nZzx4ObDvE3sF1 htrajO117R0syBz9KlD4vsTzwqCulxDUVKdZv6GDgw6cyPHH78m8edNQRtlLaRue2DafCvCNM8LH NvFAKfr7i4M/+MHSv1xzzeKbiVtRjipiBRwjxuhgmBhwIYgB685JZnIUCe0e1VOpiRN5oBSplMch h0xmjz3+iV//+jG+8tV3kUwe6BCIyYJVwiEJlyC8YDCAM8mb1wFZ2NeSqBByVZUlVFvxKynkS8w7 YhpHHjmDqqqkfgJl040BJRAmq1sJFWmLaGOv5bJk2bKRjwELJEp5ZtEg9ELCumLNEwjnWXVf5jb2 338i55/3Z5qbqzjtA3NMQxNL4gJbvzRsD267eOKN2NpNBiM4Kywr8gNbCyHo7x9kyZL1fO5zH6S/ vxAcL6VeGFmFqyGNrWXwPdhkPycGfLNz4zgGPAqICThGjDFAa6swvaBlIyKhJ39FMGGHuwMr26ER kCQSCaZNq2fqtCauueZDIAR7zGg2ZGu3ciWsrVECz/PMNRKRRkhU7hfrQHs0/YrPHWUllFGwGFeu nex9Tj11nyBrW5pYdkjY1glsr217TNvzBQMD0lu4MLdbYsDaI2AyoW12tvJASOwiR5nfEwnBpEn1 oASL7vkcAsFJJ+2NcNp8hvb2CPb0ddpQBkH8t2Br3d9ZalvbLPLAfazjx+9//74oBXV1acI4unTC 7XYAKuBd26rSvqGUjGPAY4Q4CStGjNFBRQw4ISdM8MpDP9YuQ90m0STTCO1W1J5J/Z4wxwXtDo1r Ufdojl5T9w+WCLsrjm05qWznK9/86OMQftCq0j1WKT9IViKI59pxhe7qQNkZUrWdoTRC12eQr+s0 IVECMhnkEUdk8iNleN/v7Wtr61kYqPAg8S3sP2U7e1nHbyD9TCxYq85wYURgF5tI5ahX831pG75Z WzvXVVKrdZO5HZCvMq5k6ZRWOb2f3Rxv2287PC6qshWSTFbFdcBjhJiAY8QYA3R0+GLJkkJV4HYM ypGUIVgMWQjdpckQm07UCmOBynongzpbM9HbSdv0WVZSb4agZBlNABUTcTDxO/cxSlfZpv8BSYSk E+1hXA7et9cVgfs0dFeHz2rJGEMqmmyyWZg/PzuCdcDJ4Bkx9wmfVeJWBGPHpWRgA2vfkMgqSdex tXBsrSzhmvu+iq2Dawm92AptTRAb10e4hG+VMRFHsS2z0uf4wdhdc1hvg3X/SxnXAY8VYgKOEWN0 MEwMuJRx1aSwk6M7qdvdiIQ0SozgPWWVFLZm2BKIH3ELh+pLGUVlr18O1a3QmxJo4rYqzagwwgld u2otGcggCUuZTQX0BK8/k9Le2yJUcbbcKngtAicppRIsXTaSvaDDOmDM3cN8qAqh54zHVcHu9xIS o3leZbZZDMhvGFsHG2BU2lqiMIsiJRFBzN0HETpIdHKVtb2xq7W39JGBGnfHaYk/HCcqjHMLQ+Kl Ipn29oa4DngMEMeAY8QYA+gYcLZfKdUINm5nt6rTE37oJvVCErA7IymFTv6xsUPPqDA7ZzqlPzYe GfRdDmtGbVKOu/kSgWoFXZ7jJGJZNRts8ABW+QZjtksBURnnRRO4o4hdsrDEMJDzvbsXDu6GGLBR vAKU8oKH1jZSOoZuXA/hwkEfJ1TCLD4Shgw99CIlEXoZFMPY2nOzrAgWHy4C9/2r2Bqc64Hr/gdp csBE5HC9ADB9t5UN99oF2RDvchwDHiPECjhGjNFBZNarqkJOmJAsa2UbOjrDQ6xqInRXGsUrVHis dhfLQCFbdzHWVWzjke7EjtmX15SjhC7Z0C0bupbL2NHZjGiFjwr+Z5Rv0MjCD0jZLiDCR7eK0HKL uYYy+ceGHLIZIY84Ir3bYsD2fjbT3I0FW4LSi53Q6xC4hfFNfpsMbW/9xUNsbT0Njq2RFbb2X9/W ytpbq2VhXd22vEgpUGXnnuZ4Gyu2Kj3whrgqWpLJlAszZuyMY8BjgJiAY8QYA3R0IJ5akq/SWaiO crSTvyJ8X0QJzE6mgVoyrkYdz7Qk4M6fYSwy6qZUzmcyelzkGu6x1l0uEUHmrh2vJl9hYqRDhZYf kouJsdpuVAJphKIkk1Uce2xqxGPA1lbaiWATn8JEKeviDe1KsCiw+yhbW1tlLyK2qrT1ULdw9KfS 1gxrazDuYmdMoWtZ39PGc63Bnc0eHeUdut6dKmV8X8Qx4DFCTMAxYowOhsSAV68qZsIYrjvhuq5Z pzwlcOfaydu8Gag6GwsMSdMqLAL1Zq47LMGGP8L82Mxqm0SkjNoKE4isovXNfcvBAiJUcOFzaMIN XbEKZUKn1jWK7gW9zB/hGHDdfGuv8F6W/O37NvkKh8zs4sQ+qwpsrZREBsp2eFvbetw3ZGuGs7WP MvYO7o+bXV123jcJXBC8HywcgvPAqnD7PZTKZNrbm+IY8BggjgHHiDEGaG0V8oR3ZvqVotHWpCql MP04nNitnliFqQ8OXadeeIxp3qGhY78ohTJNIpSQ6ALQMHvaSqEwC9egsmuE+751gwefWYKyb8mK zyqIy/6uQiLRitSNS0oGBqR3990jHwOu7N6l8BEkIrZGWNMo532JbWxiTREGzpWxrflOhrW1ud/f a2sFgb2FAFkOjtWnGRursvN9RL0nAbG7A1JxDHisECvgGDFGBxGHbFUVsm28KIe1pdKUsJSRyuZa mUk8yIaWRhGFqiZIyFFh6ZEKMpijJBeqITduieZrq9LsKAXgqFelygQlQ0EJTFguY8t7wkf1nfGF Wd6uWiSc/8399HGZrJCHj3gMuGuhMBxqY+bWnW9d4Pr53Wxm19VbSWZuba5dhFhbW3d2GPN9XVuL UIHzara2ClZJkGZcgc39wDthbW1rrIN4r801EMoklOlnzmT9wowZ2+MY8BggVsAxYowBOjoQS5aU q6ZMtRm1KpxMlY8yWba6q5JEkYBgUjUxP9NqUp8mwl7DSpjMWOvKtt2fRDil2v2HrUgzb4eCyxCE TY925JtAGt53FZU7X1tCCsnXkpsy5CWE+URG3e5KKTIZn+OOTYzwfsCedsuKhMkqj2Ym69Ikq1Rt O1BhnAnaq6DLikzXMuE5NxCOrdFqOVzFEBj6dW3tDAmrah1bC5udHc2CDhHGhfUlfPNkEmnL3ZzW ovY20pdeXxwDHhPECjhGjNHB0Bjw6nLGJk9FDnTUYODWDRSmncjdrGajnm1WsclyVhFFLJ1zbLxS DfnB/SH8XWc+a2Wtu3Q5Mc/hyFeVCUuVwpi1TSpTShkVF6py276yVBzpGHBt9c6ddfMt+VsPgs1W VgFxmcVKsFioLJkiOC+MF7txcpvkNtTWchh7h7YmYmurdiO2RuomKsIl3zCxLro3heOBMMpYVNZj E/5tlEpeZmt7SxwDHgPECjhGjDFAa6uQxx2X6gcag7gtEhvb1QorjNfp1/Y4o9iU1LFAMBOsWwvs 9jxOBMlBoXIzseVgUwH7tiWA4DCMwA7KcTRcIghfW5ILY6DKKHar6CxBV5TqQLClXi6Hd/fdxRGO AXu11qUfZgJHFw7K7eUckJhWuFoKO8rYfFehh4Hg2tZZEG32QXhO4KnQ/xfYtMLW4TkOearwWtHM 6fBf5SjfYPyBvaMKWoeQfZlOl+IY8BggVsAxYowOIjG1qipfTppkezc6ijRSK+qbYLCKqi0gbMyg lZLtxqSET9DiMZjYw3IXm/8cKltpznd/nNCfQMc0ldS9h6V1Y4Lb2ziMXxo3c4XSFmas+vSwvWJI GkrHmZVPJiPl4YcnRjQGPH58x0LlqPMg29nYImg9GdiaUNE6blv3WcOsZUts4TMppZCqXGFrsO0k 3Z/A1EJvGymU7SRWJvwO7fV9bAZ22LUsDAVUlpnp04Z2yAq8AEqRzfqFadN2xDHgMUCsgGPEGAN0 dCTEU0/5VVOmmG5KWLVqYdSwNKoriOl6RomZuGOQcas/Ezb+qKS+rlJW56DTunzCwhscMo2qOF2f bMfhojLO647XqlxLCK5KM0QjHPJVLhGHuyxlMnDccSNZB+zCqnNLfFaDiNA97SXxXIUrpMk9l7oj VpBUZjPP7bUShthsnrQI7GttbT8ZztZqOM5zFG/4MKE6t5+5DTaCWnCljMvaupxl8KhBcpnw8X3h DQxk4hjwGCBWwDFijA6GxIDXrClnopsbuA36lfNj44tWsRqCC5SvJTRLem7nrLBONcx8td2yZHjd ILnHdQuw8ONfAAAgAElEQVRHE6TCid+JmaoyYRcmQo0djEufI5VWvqFXNky6clUgSlEqK5YtK41o DLijo3E+gfKzJViWuBziEwrheCPCbGQ3xqsi54eK0trGKOk3bWs1zPthHbL1MISLJquoo3Fhrb4J r2PizAoC5auvp+uLSyUyW7eOi2PAY4BYAceIMQZobZXyuOOSJgaMmdhNLSqg18ZGrSkPhY/wEuTz Zfr7i4wbp7e3FTZRSAgKBZ/BQZ/GpqxzDa2OpVL09RZZ/vJOlILJkxuYNq1x2LFF61UtOeq5uFyW tLf3MXVqLVaz6U8rlZomHCGUeQpTBqNCwlEO4QQkBQwM+N7dd5dHvg44qPv1sfsuR+Pv1taWBJOm Rtl+N2A9CeG/Tr2vUcS2flcE/PXqOidqa2uPaJ60m/ls/Rk49rbfgjCdxvSo3MWF+VeFBB1uACIA GceAxwixAo4RY3QQ8S+m08hJk1Q5UJmRmqCwI5OrepX06esdZOlLO4goVCEpl0ts3dbHI4+sc2K4 YYZufrDMX/73Zb7//Yf5wQ8eZsGCp9i8pYtQtblq2cQ3cTJ3zXsDA3kefHA1UtoJPNoxy40vWoVr M7KtSgwUeiQzN1TbVVklDztspGPAnQsr72PtrpzxuR4GgVvb7KjO4FndVpPh++AHCWvKseXr2zqq vN3rWVUdtL6MxOttHF9nO4eqWEa+w0jiXLD7hk867RemTdsax4DHALECjhFjDNDdjXjqKVl1+umW qDwEVn0Fe9uEtb2GzLJZjylTaikUyqxY0cFAf4mWlhpmzWqiuzvHypW7yOUKbFjfw8BACaXgoIPa 2Lmrnx/+cDEPP3w+Sil+9rMneOzR9XzwgwfQ3t7Hhg1dVFenOfCgCRQKPhs39NDdnWPChBomTKil qjpBf1+Rzs5B9t13HMKDvv4CLzzfTjLpscceDbS0ZGnf2suGDb1UV6eYc0ALyaTNFK78cffhNa0W TdZ2Og3HHccIx4DDbRU1p9rdjLwwq1kQZoVjFwhWHSfQmyUIJ5M8jJ+Hihgd0w12giI8xpwXLJCE Va5W01aWCrmvFNqvLJ3Fmn49xAsRKGYZ5MxHwwaO90EppJTewEBcBzwWiAk4RozRQUUM2EusWaMy ypQPCeG4HpVCt5bUWxQafyZSKnZ1DPL8C9tJJAWXfvkBamrSzJ7dzLe+dSzJpEBKxYb1XVx88X2M H19Nb2+RCy88gpkzmxg3rpplL+8gmfT49KcPIZVKsGtXP1dd9TdefnknTU1ZLrjgcOrrM3zta/eR THq845hp7LdfK/OPnc4996ymp6fAqlUd7LtvM3fcvpLrr3+Buro08+ZN5JOfPIBfXvUsy5fvorEx y+c/fzCHHdZGWHOrn03hB5Rj47+2R7RSinLZZ9kyOcIx4Jb5oa2tGvQ0WYlEkJik7DeFIcaAbG27 TzvmkIiDZwheg+tcDCu8/Io3zD8ijNECTu+ToWpde5JlsFjRfxqy4njb8MTexOktHSSQOXXXpURm 69bWo4GbHbPFMeBRQOyCjhFjDNDaKuX8+fTrVxXJSMJNEAp3CVJK0dNdYO2abrq78qTTCb7whbkc dNB48vkiNgkrlytSLJa57rpT+drXjuY//uNvNDam+ejH5vCD7z/KD3/wKLfd9jJbtvSwfPkO7rtv DVdceQLvf/9s/v3fF9PXV2Djxh7+6w8f4PjjpvPLq56io3OABQue45BDJ/D445vZubOf733vUW64 4X1cffXJLF26kxUrOrj//vVcfvk7eN/7ZvL97z+JTRQL4pa2AxcQqrJoItPAAN5f/6pGNAZcLlPr lt5Ek5H8CrIL1bJNYEIpU4bllP24Cwui35m9RlhrHCZaRTaDIEycCzdl0CVZCOlkMdsYrm1wEiaH BRszYBt4GBd60HIytH34vK4XQsp0uhjHgMcAMQHHiDE6GBIDnjjJLxOZoENXoe7dHMYCbRw1lVJ4 HrSMy7Dvfs384hfP8swzWxnMlwIFmckKjj9+GqkUtLXVsHNnDiklBx/Uyu23n8V1151CKiX413+9 m/b2HopFnxv//CJPPLGRmXs2IjxJNpugujrBhAlV5HJFHn98I+m0R+u4KqqqdGMPzxM0NWdpaMxy wb/MpX1rn77WjSt48sl2Zs5siCjbIBaMwu4jHFYm2zpgRTar5GGHMaIx4NYJOxcibI1yZfmTUYTY ZLCKmuyAaC3x2uOUWfSUo7Fa7LMO92OyxlVZ2wBb6+vEfIOWncZdbM812eTYns4V2emR8iM3Tk3Y 1csSdJBfoBSZTLkwdeqWOAY8Bohd0DFijAG6uxFPPkHV5DOdblSE+7oqod/TrmlTJxwoNkVPd57j 5k/hfe+dyW9+8xIrlu9iwoSaIMO1psZ6cCWJhGDDhi4uvPAefvijd5JKeUxoq2Hy5Dr2228cc+dO 4IwzZtPVlWfT5j7jBtZKsaEhw4c+tA+XffMhFvznKcH1UmmPadPreezRTfT2Frjhhpe59NJ5HHxw K6efPpOurjxbtw0EYwjglBwp5Qc7D9m9gkGSySjmH+ePbAzYMFdQS21tbQ5RJIytIYwPO/W8QSw4 uCJB9rFxTetv0i0Rinpxw6xom7QVHWjglq/IhLZtq4VxNytpFwIQZpFX1pBbl7QbV/axu2uhQuL2 pfRyuZo4BjwGiAk4RozRQUUMmMS6dV4mUDsVLQ6FTfyxqkV4IBTV1R577VVPbW2S3/72JaZPryeV 8jj88Ans6sgzbVodNTUpZs5sAHxSaY8jj5zM1Kn1vPvdM/nhDx6nqSmLAn7ww+OprU2TTHpcffXT AFx+xbHk8z7HnzAd8KmqEvzTP83kqafaOerISfT0FDj0sAk0N6W56MJD+dGPnqSmJsVHPjKbSZOq SCY9fvWrFwC44sqjtDrEbqLoB/tB2HaJmgdsH2NNKeWy4uVlYoRjwOPmh5tc2FafEmViwjrj2ZYR SV2mFChGsxGGqCBiKpKxlCbygFg98IIkqTDlLFpG5CbZuaO2VdSKsJmHCk9x6qjD7RPd5hwghO3o BdLdnSogX32NcsnLbN06Po4BjwGEqlyGxYgRY8QghEgCaaAKqAHqgcaDDx63z5VXHv2jQw9NNOqa VGGUlJ33PMKEoaTTVzgRXFspj2JJks0knfPsge7cGe6U5PsS3xek0gnzif7vv1CUpNOJ8D7KVWnS STAybk8nIUgpheeZ41EUiz7ptE0os0QhI0Qcso2NR4ZZul1dissvL+668cY7/xnYBXQBvcAAMAgU VXT3AdfeKSADVBt7N06e3LbXe997+C++/e3kBGtrfay1G8bWQttXmK7Rys14Brvnsoh8R69ua3vd yixlFdy/wtboftPD2to5zu06FvY5kxFbW9iENzf+HYY6lLG3LH/rW/0v33zzfVcAO4Ae8zMA5ICS Uqo0nL1j/H2IY8AxYowOIjG1qiohJ070y0IIJ/HGZqaaZCVhE4bKQbwujDeC8BSZtI3lySBO6MYr w8QfaeK2kEph4oVh/DWTFsa9qRONot2dnLrTIJ4oAZ0oJDwnsUj5pFNUxC9tiY8knPjtZ6E71cZn MxkpDzusPLIx4NatC4VbR4ujwgUQ2NrX8VkVjjH8Bm0s3i4o3Ppea2unV7SSOuZr4rP2zoHtK22t orYO3NHWlpW12U5cvdLWmrTD7OfozlVulzJJNlsuTJu2MY4BjwFiAo4RYwzQ3e2JJ5/0quykKJwJ 3G49GGxtJ5Qz2UMwSQd76Tpb4AVdjiqJwSXkMEGHYPKubMtoCDZ4bbNmLXG7akoF9w/pzW1ZCbb2 VCmFkuUIGdjYpC2NyWR85s8vj3gvaPvMwrW3KqN3iFChrU2pVGjrcNGj4draVZSu/ZRznE2uei1b y2HOt8Rduaiy93I3voja2va1VtJtFhLeK2yeovB9FceAxwgxAceIMToYPgYcKSOx5IWZ9O387k72 bmJNSLRhpq67O1GojCu7L0npUygUzbFlCgVNtoP5AuvWd0KQnWuvb+9hxqhU5Hrh/fU5Uun2l4pK 1ewSmT4/7F+tf4pFWPZyYoRjwOPnB524gsWAVYJOVynlkGvE1na8Q20tIx4Kd/Fjs5tlxftW77sK ulxh69DeuOMakpWtvz8ZuLGdxdgQ0g7Vr11QKCUplkRm69aJcS/oMUBMwDFijAGam305f/5gf6BI ROiatBOnEL7jhq6c1MuOOxLn3KjSjZKAmfiVpKcnz4MPbkQqn+6ePA89tB4py2zc2MPPfvZsxM0Z KF3llMw4PYWVLJv7m9juMONRslyhmt16VYLnFkIyOCi9RX9NjWgdsJRebdiAw5TsBPfVcVYhoi0z o+VB5SG2tsrSRNej303EO2CJL0rcld9NtD7YJdyogra21u+Zh3Tc+0qZRYFD0lH1a7PPtb1RZZlK FeI64DFATMAxYowOKmLAUk6cKMuhKnMn+QrSFNYNDdKJD4aK0lVgNtYXKpywHEV/lsuVuOOO1Vxy yWJeenEHd9y+mosvXswrr+yiu2uQRx7eQkAAthlERW2qJeOgrtSQk+teDZSWKptt95xxOK7dIH6t dGlQJuPLQw8tjVgMuFjs7Rs3bvNCV6UGewJbpeu6hYU/1NYBkTm2Jqpsw2en4rUh3CCGXEbXA5v3 hrO13WfYUb9BX+khttb2lMH3osyQnbCAcrwNFb2s01m/MG3ahjgGPAaICThGjDFAd3dCPPVUuioa O4XQLeu4MwP142YPKzPphjFLXa6kTBwTVODWdNWRpLc3z+9/v4KBgRJ/+tPK4Pc77lhHIhH2JXab TQTxyMgm8maid9ymQoQubiXL4JBFcN2IKzp8fjvOTEZxzDG5EYsBJxI4is9NQrKLEuuOtvZ+Y7YW bsw4opotIbuNR1wui3LbUFurqK1tNyzjXRhq67Kxte/YujIs4MbpCVzvoFA+cQx4jBATcIwYo4Mh vaDXrk1ktLvQJji5MVs7uUfbG+JOzJYo3LiitMqmbNomQqhQtcJqbEpx0UUHUl+f4otfPIALL9S/ n3vuXo7is+RUxs3CjqpBd0ee0L3t7hA0NPknGpuMqkS98CgWJStWJEcsBixEbXVHR9t8HSsNyShi WyHNYsGNr7+KrYNsZSf73FHKEVsJ12Vsk7lc21a+Lg+xqb3v0Pu8nq1VaG9hFb1tPxkq6VJJZLZu nRzHgMcAcSOOGDHGAM3NJXnccbl+EI3abZg07ly7AYCdeMMuWZXQqs7TUUgl9Xw/ZMq0rmjb1QmS SUVraxbPE7S0ZBk/Xv/e0JAB2546MqmH97apPq6gU0iQlR5LGfk3yPa2cVjlHhOtC87l8BYtqhmx GLDn6RhwYFORCO8vTNcrZbVIgte0tcJ8HaZHt3nDei8EIrS1QH+m3C9FhY9qXkfhUwm3V4NtKYly 7f1atgbbyIOgtMqxux6RTKX8OAY8BogVcIwYo4MhMeAJE0pBL2gVKflx60jd+GhUEVeqx8C1auN9 ThxZBHXFuv5UCEU+7/PsszvwPEWh4PPss9sB3Woy2r/YrTt1YpK2t3HExTlcgpEfxrErnsueG2YE KzIZXx5ySG6EY8BbFgYuV3zH3m/W1q5aj3ombI1wpa1D5eqeH/68mq3dTSPCjRZcD8KbsbU7VgJb gyKdKhamTFkZx4DHADEBx4gxBujuToklS6qqgok5SKAqO+rGJmA5E7eZXKMTvyQsnwljmsKZmKX0 dVxW+QhPMm5cktmz67nhhlWMG5dh770b+OMfV1FTk+Soo8YTurOdkpgIQTmkG5nclUMUTm2sqjyu 7MRhw/inUmUyGZ9jjx0c4RiwNLfwI/cieA4V2vdVbB0sNtySoMCta9WnH7F1SPYhgQ6XYa5tXR7G 1rZm2trIvb/rcn4tW9syp3DMOMloUgkvl2uIY8BjgNgFHSPG6GBIDHjdumQGs+mPJmLdClKpctiW UkU7B4ewmzUYp7AqmX7SoCdaz3F1CnNs+Gr69BpuvuVE7MVvvvkE7Iuf/vRwndQT2Tug0t2pIv/q Q3ztd1XSGa/rFgUbexTC/q7PVg6plEqSl1ekRjgGPHG+7qqYINy/V/+uW0cqFAIRGXtwBUydUjhW EQ2QRt3K3pBQgG6/KSqO059g3drm5VBXvnX5mw07wNjahiqGc0E759rvKIhdA5TN35qiVCSzffvU o2Fp3At6lBETcIwYY4Dm5pKcP7+3H2SjUknCSVf3GHZJwo0BV86IYXzQxIGDmd+6Gu2ndvJ3e0UP 52V0mGBYB6QbH3XOr4gzhuNz443KPJN9FtPHKbIZg08u53n3Lqob4RhwQseAKaPjvMKMKRGoUG26 JJW21vzoGZMYtgwI0D6bu9mCGsbWELVdxR1e19b2PoQekiAbfegiZyiJ2ydRzufWBsR1wGOE2AUd I8boYEgMuG1CwdQB23IhCGp57f8cN6QblxzaXcnGHd26Wtvi0XFpD4lDVsQxX+V9FbhgbQauW0sa dYeGLtSSc89QhWmXuHaLh+0uCe6bzZblIYf0j2AMuKtv3LhNC0OXr7U14XNgXcJDbc0Qe7vu59De 1tZhfPXvsLWjXitd/9rr4brGK0ICEVv7xtbu/bStbXOXdDqOAY8VYgUcI8buxbCTWHd3Six5uqbq tNMGCdfBJexuRyJQKHb3IztxGvUmrOoB7fL0UapyPe0F5+l9iIa6QO3OPUGd6pDPzZtDTsRxfUJU rUnntUtG9gahCtMZwiF5KCVJpxXveEfviMeAhTBZ5nho4ofQ3voRtcfB2tpmoBt7K1DKM9exn+P8 HmYw62S4qL/ijdkagizxiIAOvwP9j2vPkHQ1nDrtwNbuV6gXPdYlLaUyMeDNxBhdxAQcI8booDIG 7K1bl80o1VexDaGGdkuDnTyFiBKxkoY4hIkLBpOyZ97XtwzdkobSzZ62djK2/9rJv3K1EE7alvDD Rh0Esdxo3FETmR5rGOO113Hdo64LNSSLUkmwfHnmtWLAb0qZCdFQ3dExcb5SPea1u31jtExLx4Q1 8dr4sPb4Jips7V7fPnfU5bz7bG2PcW1tY7xuWKLSFV0e5n2fUimR2b592tGwzI0BxxgFxAQcI8bo IOLSa2nJy2OP7exTSjaFhyTD2s1gsrRkoSdXGRCvWy9qydkhFDzd/CG4e6iewo3l3Unf/mL2orXx Wn1XKo8KNokPkoZUeISQaOKpTPixx4bEGzacAEsMuZzn3XtvcxUjBM/zPN9P1oSLBB0H1nbwTFJY aG/t5rUu6kSwmDBXYwh5V0byRtzW+v2htgYCVQ9hLHs4IraLJNd9HYQTZDKZ7xrGdDF2M2ICjhFj 92OI2EmlpGhtzfULkWiyZCVEGaW0Gg43ddfEYBWxJgphJn1hrhyScaCUlY9yFLUru6zbOvJ2oM6M 4g7iiPYD90miyUHRrfrMeUHCk3mlLGGZyV9pZacTi/VCwRJfOl329923q4ehccg3o3yDFUF/f1dP Nrv6f4So+zwgrGrUj+YqWxHaVyXQZGaOC5p3hISn7ZVAJ0P9Pba2NhrO1kNDsZX2jpRzOdevTNoS QdjCXQD5pNMy39Cw9j7XZlFTxrHg3YWYgGPEGF0ogFKpPvXcc5mBiRMLJINexa5L1BJxVBGHGdNl wDOTtee4P63L2nWHBmwTzKQCzUJuErW+/qvk3kTe8h0S0R9WkkqovlzFqwIVFhCvQzI6jg3JZLk8 a89drxCyT4XEfl1EzhsYKJSWL+/ZsGtXTWFci8iKQKHLYYjYI5rIZLLFlWsj64WwLutQgWpCrrS1 vZ9TBzbERhWjd15Y5S4qzgvd/JXXiSresFQtGhu2Ncs9Pci1axN53J6mMUYFcRZ0jBijA9f3Jzdv 7ul84QW1qa/Pz6lgh53KHXTCzRTCDN7yMO9Ls3Wh7UzlZksP34VJ94ouoZT5kebH9iIOOlNVZPwG PYT1jzQbvuv7uz2jpTNOFdzX/h7s2hRkeWsyKBUlGzYkC48sLq3Gzc5648RQSdoKkqqjozbxwAPp DcWSlMFuRAG5ycAmOM8XLnR8530cW/uOnSWW1Iba2j7jcLYuv46tK+1djnzXw42zsjFHZT/r4DuW PoWC8p95JtW5dWtDkujfaOXCJ8ZuQEzAMWLsfkTIF5A7d/b33n//i7ctfbH/2Y4OlevvB73VnSSX U/T1aYXm+z79/Yr+fn26UpL+fujtJZjY+/slfX0EBNHXJ+nrCxVOX5+it9eSpaK/H+d4/VrfXyGl oq8P+npBSX1OX58yx0uULJvx+MF47fWkVMF49HiV+VzR2yuCDlEDA8JcTxNYsajI5xVS+nJLu+z+ 7W8zKxctSm2HyHZOb5YUApuXy+Xi8uXtaxcv7rxvzZrS5kJBFrX9dHeoYlHS2yvsGCiVtD0LhXBz iJ4eSbHoo1SJYhF6ewXFonLOVxQKemeiQkHS06MoFDDnK3p7oVDQwyqWlLm+tv/OHUV6e9D3N/bo 7YViQX+HpZJPX5+kUPDN9fT3f++9u1i7ts+MV5j7+RSLip4eYa6vn6e3V1AoaDNKqb+zfMEvbVhf 2Hr33V2Pr169bhVRBh/O+xBjhBG7oGPE2L1w/YOWhH2gvHZtqeeyb+9YeNZZVcycmd33wANzQkqZ WrOmPl0sJsScOd2lUinF2rWpVLGYZM6c3lKp5LF2bW2qWPSYM2egJCWsWlWdKhYFc+YMlJQSrFxZ myqVBAcckC8pBStXVpvXuZJSCVauTDvHJ/XrksecA3IlpTxWrsykSiWv4njPHO+xcmWV81qxcmVN qliEOXNyJd9XrF5dE1xfjzeTKhYTzJnTXyqVBGvXVqcKBcGcOf1FKQUdHWmRyyFbWgY7Hngg9/yd dy5/pLdXbmd4Qngj9rbH2/PLg4PFgUWL1i4pFhsGP/7x5nf199fuccABPTKR8L2uzlRi0+ZMsq1t 0B8/vig7O1Pepk3Z5MSJeX/8+KLf1ZXwNm6sSU6cWPQnTCj4nZ3S27gxm5w4sey3tZX8rq6Ut359 NjlxYsm8Tnjr11clJ04s+m1tvt/VJbz16zPmc9/v6vKc1yX/619fkzn11H3Vnnuqis+Lfltb2Xld 9tva8n5XV9pbvz6d7O315PnnP5ueNq1KHXzwePXudzeUDz3UK3d1Jb2NG6uTEyeW/fHjC35nZ9Lb tCmdaGsr+W1thXKppNSyZfUim+3dcvPNux65886+ZUABXQdne1bG7uhRgHB32ogRI8bIQuialhSQ AaqAGqAOaAJagJbq6uyE2bMn7DN5cleitTXb0t3d2ur7XqqxcWunlAmvr6+10fcTydra9sFk0hvo 62ttVCrhNTZu65AyIfr6mhsh5TU0bOuQUoj+/pZGpZJeQ8N287rZvN7hfJ5wPn+jr7cF1/N9r6qp aWe7lIj+/pZGKZNeY2N7h5QJ83nCa2ra1iGlJ/r6WhqlTHhNTVvMeMc1SOl5zU1bdiIS/uBgdaqj Iz24fPmGF9rbizuAHqDD/HQBfcAAMIghCqUiRciV9k4be1cbe9cDjcA4oLm2Nj3h0EP3nDdx4i5Z XS3TuVxt/cBAY2NVVV8une4bLJWqM7lcU10225/LZPpy+nVDXTY7kMtk+nOlUjYzONhUV1XVl0ul +nPlclUml2uqq6rqzaVSA+Z1o/l8IFcuZys+D18r1Vu4+eZt8/bZZ/LOOXNq2sPPGyuu11BxP339 v/1t06SNG/MT7PPX1Hi5yZPrutra2ooTJhS7s9n+gWKxKpvLNdVVV/f2VVX19hYKXmnjxpbEiy+u e76vr7AT6AY6jb07jb370X1SX9PeMf4+xAQcI8ZuhCGEBJoUqtCkUIsmhCbz04Am5VpzTBpN2ra+ aE9gHvAwsJWKPNkxeF0DnAT85U2cP1w2s49WXUU0ufajJ/8eNPF2ocmhH93IedAc678OAScJ7V3D UHs3Ou9beyeJ1nNVjnt32XQv4Fg08f3vWzg/A5yF/nupHG8PsBZYZ65vEwgKaHIdAHrNT5c5pgf9 HeTMMUWgHBPw7kHsgo4RY/eiMh24jCadQfTkmSba7qpo3k8B49FEN9kcv5K3h0twb7SazAA738L5 1rVZScA5NNkOEBKAdYu63SNeywb2M+tGda9v7ZpwPi8SLnjcIt/Rwh5mzM1mHG/Fno8BJ5jf3bHX AwcDc9F/O/9LlICtve0CJyBcoq7/GLsJMQHHiLH74abFltATYBK7PY+G/SyPVmjHA0cSTqgvoRUK jL0C3sf8uxd6Yn8rCriSgAtoewwQKrDA5Uw0GetVoZRSQtdC2X6TRbStk4Qkq5zP8kQVsEvAu1sB N6AXV8I8l7Xnm73eQ8B+QCvRxFp73TxwO/rvxy468mj7Wvf+AI7LmWjaekzCuwkxAceIsRthCMFV v57zU6l888C7gY+iXdWumnkc2DVKw34tTEVP9AAHAjcQdtx4I3Aza12PgKvKLBG7BByoYPX6cTM3 2c0SvLU5hOSbJeqFSDjHjIYKPsT53eOt2dPiBuBLFe9ZO/0aWIW2SYmoV8C6/l0Xv7W3AuQbsHeM t4iYgGPEGB24ik84P5Z8ZwGXoN27kigB9KHdjG+HONwphE2nq9Au1EffxPmui9gtFrYqOE+ozqxL 1CqyN0oE1tbWpexu7CCde6UJyddVwDA6BHy4Gau9VxUwE6jcmeiNYDtwGHAM0UVEAa18t5t7WVta G1ibW3sXiLqgY+xGxAQcI8buh1VklnBLFe//GzqRxk54rhtRAg+iJ9Cxhoee4N22W/OB297CtSpL hVxlZsnBJV+3Fvg14XgdLMFbV7K7CLKu5wRD47+jQb6zgUkV7/nohKxb3+I1f4pO1suY148BU4Bv A78EbiLqGbCeAOt9sfHfEm/C3jHeOmICjhFjN8MQAgxVFJYkbkG7nmuHOd0D7kRnA481jkHHpy0S aDdqNdD+Bs6vjAMPqdclJICS8zpICHoT7lAb502aa1UScIowNmzJ1/5rsTuJ+ATc7as0rD1rgC1v 4ZPYf9kAACAASURBVJrdwK/QrujlwIXmmt81v+8BXEZU5Radf4eQb+x+3r2Iy5BixBglCLvPXTQG bF2fewD/jU7EcSf+HvSk7DP2+DnwXsLYNWhS+wVafb0RVDYmcTuE+UTJOKJ832wpjAi3InLju0nn tbsv4XAlSLsLCeAZoosZF78A/uMtXjsJ/An4IrpkDbSN/xVNzC8C56EXTNbOsuL3t2TvGG8eMQHH iDGKcEjBkrElBg9NwKcQZupK9GR6EaNbGjMcaoBXCN2bFgrYBhzE67srh8uEhqgSdhOoApX8VpWY Y29r80TF767qrXQ/7y6bvwudNPVq2IIuHXqrk7PdUQKiC56TgevQCvgThHkFbslRrHxHEbELOkaM UYSZ2FS4W1HghvwaWl1+GZ2dezmaIG5GJ8iMNQGfyVDyBT2uicBRwP1v4DqvRsJ28odo7PHvIgPH 3jYO7Lp9XSU/WuQLsAI4g1Bt3ggsBH5DSIY2PjsSsPa7HXgZ+B/gDrQivpYRtHeMN4dYAceIMYYw xHAquqvUDcC56Mn/PWhX5H68PdzP96Jrky1pemiCsGRxE/CZN3nN4RprKAiIc8Qhovs0UvH7WC1y dgHXo7PgdyesTWuBPwDvA34LXKCUKrzqWTF2G2ICjhFjDCGEmA08CawGjlFK5Z3PapVS/WM2OAdC iIQyG8oKId4D3A0cqZR6cmxH9v8+hBCdwB+UUl8cxXsKtJflm8BTwBlKqTeSSBdjBBFvRxgjxhhB CFGPbg9YAE53yRfg7UK+ACrczR2GL5eK8dZRmQ2926E0voV2he8HPCOEOHo0xxAj/g8oRowxgVEg N6A3WvigUmrTGA/pzSAm4JHFqBOwhVLqf4Ej0M1eHhRC/PNYjOP/KuL/gGLEGBtciU66+qJS6q10 PhpLWDWceM2jYrxR+IyhLZVSy9Fdue4DrhVCXCuESI/VeP4vISbgGDFGGUKIM4CvAwuUUteM9Xje AmIFPLIYMwVsoZTqQSdl/Tvwz2g13DaWY/q/gPg/oBgxRhFCiAOA3wNPAP8yxsN5q4gJeGQx5gQM oJSSSqmvAx9EbwzxjBDiiDEe1j80xvxLjxHj/wqEEE3opKte4Eyl1EjVeY42Yhf0yGJMXdCVUErd gq7rHgQeFkJ8aoyH9A+LmIBjxBgFCCESwJ/RzfHPVEptfZ1T3s6IFfDI4m2hgF0opZai48IPAQuE EL8UQqTGdlT/eHhbfekxYvwD4/voFoQXKKWeGOvB/J2IFfDI4m1HwABKqS50a9QfocMl9wshxo/t qP6x8Lb70mPE+EeDEOKj6C5Hv1RK/XasxzMCiBXwyOJt5YJ2YeLClwIfAQ5Fx4UPH+Nh/cMg/g8o RozdCCHEXOA/gUfQmyr8IyAm4JHF21IBu1BK3Qgcjd6u8BEhxDljPKR/CLytv/QYMf5fhhBiHHqz +p3oZhvlMR7SSCF2QY8s3vYEDKCUegEdF34MuF4I8TMhRLyhz9+Bt/2XHuP/Z++8A+Yqyv3/mbP7 9p68aaSRnpCEktCkIx0U6UVs13st9+dVr4p4L4qIiiII3gsXRUCRIihFQBCQroC0BEgQQkIoaSQh eVPfvvue+f0x9ZzdfUuy7/smcL7Jvrt7zpw5M98z+zzzPPPMTIKdEVow3QEMRy0zuW6Qi1RMJBZw cbHDuqDjkFI2Aceg9iv+OvCIEGLY4JZq50XyA0qQoH9wBWr3oC9IKV8a5LIUG4kCLi52CgvYQErZ JaX8FvAp1DKW84QQcwa5WDsldpqHniDBzgIhxOeArwKXSym723h9Z0Xigi4udioFbKDb9oH669NC iHMGszw7I3a6h54gwY4MIcS+wDWodXW/M8jF6S8kFnBxsdO4oOOQUr6Mio5+HrhFCHG5nvOeoBdI fkAJEhQJeu3cPwGrgDNjW/h9kJBYwMXFTmkBG0gp1wNHAVcC3wT+KoQYOril2jmw0z70BAl2JOjd Y+4E6oGTpJQbBrlI/YnEAi4udmoFDCClzEopvw58FuWWnieE2GOQi7XDY6d+6AkS7EC4CiV4Piel fHWwC9PPSBRwcbHTK2ADKeVNwMFAGviHEOKsQS7SDo0PxENPkGAwIYT4MmoLt59IKe8c7PIMABIX dHGx044B54OUch561SzgNiHEz4QQia7Jg4SUBAm2A0KIA1FjXw8AFwxycQYKiQVcXHxgLGADKeX7 wBHAL4HzgAf1bmAJPHygHnqCBAMJIcRo4C7gHeCTUsqwh0s+KEgUcHHxgVPAAFLKjJTyK8C/AocC L+r9sBNofOAeeoIEAwEhRBlqmckK4BNSys2DXKSBROKCLi4+UC7oOPQGJIeifivPCSFOG+Qi7TBI FHCCBNuGXwN7A5+WUr4x2IUZYCQWcHHxgbSAfUgpn0eNCy8A7hBCXJyMC3/AH3qCBP0BIYSZbnGh lPLPg12eQUBiARcXH3gFDCClXAMcDlwLnA/cL4SoH9xSDS4+8A89QYJiQghxOPBzlPv5x4NcnMFC YgEXFx9oF7QPKWWnlPJLwJdQQVovCCF2G+RiDRqSH1CCBL2EEGI8cDuwGPiMlFIOcpEGC4kCLi4+ FBawDynltShruAY1LnzSIBdpUPCheugJEmwrhBCVwD2oBQZOklI2D3KRBhOJC7q4+NApYAAp5T9Q 48KvA38SQlwkhBCDXKwBxYfuoSdIsI34DbA7cJaUculgF2aQkVjAxcWHxgUdh5TyPVSE9G+B7wP3 CiFqB7dUA4fkB5QgQQ8QQpwHnAX8t5Tyr4Ndnh0AiQIuLj6UFrCBlLJDSvlvwFeAY1HjwtMGuVgD gg/tQ0+QoDcQQhwD/BT4o5Ty0sEuzw6CxAVdXHyoFbCBlPKXqMCsBpQS/vggF6nf8aF/6AkSFIIQ YjJwG7AQ+PwgF2eHgRd8lsiP4uBD64KOQ0r5FGpceAnKHX3BB3lcOPkBJUiQB0KIalTQVRdwspSy dZCLtKMhURrFQ2IBe5BSrkTtqHQT8ENUgFbN4Jaqf5A89AQJYtA97puAacAZUsp3B7dEOyQSpVE8 JFzGIKVsl1J+Dvg68DHUVKUpg1uq4iN56AkS5OJ7wMnAuVLKJwa7MDsoEqVRPCRcFoCU8krgKGAY alz4+EEuUlGRPPQECTzowI+LgJuklP872OXZgZG4oIuHhMtuIKV8ErXu+tvAfUKI8we3RMVDooAT JNAQQkwHbgHmoZbKS1AYidVWPCRc9gAp5XLgIFRQ5MVCiDuEEFWDXKztRvLQEyQAhBB1wL1AG3CK lLJ9kIu0oyNRGsVDwmUvIKVsk1J+CvgWaojoOSHEpEEu1nYheegJPvTQ26L9HpgAnKajMBN0j8Rt WjwkXPYBUsorgGOAUcCLQoijB7lI24xEASdIAD8CTgC+JqV8erALs5MgsdqKh4TLPkJK+RhqXHg5 8KBerW6nQ3qwC5AggYGe/uNPuhex9/7AKai9Sa8DrhdC9MdvQuqX/51i7abUDW/xz8VEF5DqJ758 hN5nOdA7UHmLQBTisRj8hkAghBgIK7gQf0Vtk3H0cjENP02+csTPLwMOQK0j/TMhxBzUgjntvbx+ W87b48XgKlHACQYVMeWRmjt3bmVVVdWQIAgkQBiG9kfhfy4GFi9ePG3dunU3CCHmz549+/La2tpx xczf1AEgDMMuIUTbihUrtr777rshEAohjHLps2LxeDOv9OzZsyuGDh1ap+/Xb7wBzJs376qqqqrX ZsyYUVTOwPFm3js7O2VHR8em+fPntwshunAdmn5RyHm49V/9gduAtxgceex3DkMhhPm8XdzGOy7H HXdcdSqVquno6JCtra1bn3nmmTbvvhx55JHVJSUlNdlsNtTnIwvfdHO+AzgnnU6/ns1mL6yoqJg3 Z86cX/fh+j6dD8Owq6OjY+uTTz7ZmqdT0WfOEgWcYFAQE3LpuXPn1gwfPnx3kS4bV1tTOV1K2Z8C D4DFixcfly4p6TryqKOer6ur+9f+vJeQMtvW0bGmsrL2rQkTJix94okn3kWN+xll3CuFEuMtAFIH HHDAiNra2pmlFRWjK8orJ2ujsV+5Gz12LMBH9KvfEIDs6pJd7e2ti4cPH756w4YNC55//vlNeLxJ KcOe8ukN8nG76667lo8ePbpSSlkRBEEKoKurK9Dts1jYBDwMTCxinnnhKVjCMOzq7Ozs7Orqalu4 cOEWVJ2NQu51m4zl7/9uBSDmzp1bVVJScoYQYkZlZWVnRUXFfFTAowSYO3duZWVl5RlCiBmlpaWd lZWV8/R5ent+9OjRqzdt2nRDbW3t8FQqdUxfr+/teaCzvLzcPy8Bcfzxxw/t7OxsE0Js9Y73aCUn CjjBgMP7kZYAYp999hk2Zty404aNGPHVmpraxiHDh68LRJDOr0IEAggRQsgQRO7QWeClVZCx7wpT dpsdIOWWmpraXi76rvIJ/W/SDN91RYRbzmVSys2bN1dt3bw59d7yd/98xBFH3PjYY4+9CGRsBkro FfzR6mAxoxyCxsbG0lmzZk1qaGg4c5dxu36psqoyaGhs3CQQIpc7fUBKIUVA37jbVl3jX1uIOxCi gFtUHw1lyIZ16+patm7dmkqlrjzkkEPu+fvf/75SZ9elDZHttdh8blMjRoxITZ06dVJDQ8Pe5ZWV u1TV1IwRQRBRvP7noFhDuCabonQpHEIvQyGEFEJIQro62ls3dbS1vTdixIjXX3311YVr1qxp1ncX uE5Or9ytfgdml112KZs7d+70tra2ytbW1tVBEHxOCDFBStkFTALuM9eVlZXVe+ezqI7I/X09P3To UHN+1225vo/nTfnlwQcfPLS0tPSrQoi3jjjiiPsfe+yx9R4nKlEB/hIFnGBAoX+kAartiWnTpg0Z PXr0p8aMHf+DAz56ZDh214nlIuXWfbWaxLwJEHkUBwjb2GOHERHhKCPnQBht4JUR/J+L+e3IuJ6Q kujPSkbTS6ky0hlKKdmyaSMP33v3Oe+tXHHg3nvvffK8efNWoJSwQRgtpClTVPkCJZMmTRrb2Dj8 vMnTp5160FHHltYPHWqmUxHRwN1yJ0z++Q4r7uzIV8/cxQiy/EiiXCh+omnV/xh3Ovcw7OL9lavq HnvgvgvfW/XemBkzZlyyaNGizbokWZ2si21AXPk2NDSUzZo1a86wkaO+vMvo0ScObRweVNfVlea/ 2LyJPCPvefpBvS+Vfu9e7zmG9EMyfBd6Ln67RtLe2t61ZXNTZu17760PguC7UsqH1q5d2w50eoXo UQn7ynfMmDGls2fP3j+dTl9SXV2dbmpqOjmTyfxMCDFTStkZhuHLuKhvuXLlyi0NDQ0/C4JgtzAM M0KI+Xh9wR3lvCl/7LwsLS0dBpxTVlZWkUql6mfOnPnr1157LTIOXYg/McAxDQk+xIhbvrW1tZX7 77//R8dNmHDrMZ84NTVq3Djb6JX8MsohsMdEEJVyRp6rnIU5Gr+vl6kfRWHOx4/L/LIr8lvxlYiv iK3GQUoZVdoSJCGtza088cB9Gxe99upN99x1149RCrgTbdEBoe9W9XhLoX74pWPGjKmdM2fOWbtO nvLzj595DhVVlX4VI9wJLZsdd8JPEk0fGeqUfeRORiw3idT5SU8huDiWvNwZJewpY5VWImVI07r1 PHj7bWvefvedbz/y0EN/0bx1oZRw13aMpaf0q+yggw6aPGr06Ctn7r7n3gcfc1xpWXm5o8DyKhxb gUdQTttTf4Q9JyPXOwntKPBuo7jxqmQ4KcSrz2VECXfDazaTYfFrr/LMI4+sX7FqxZeeePTRJ1Gc FmyTBTgESO2zzz4jR48efYMQYr9MJnP/kiVLvrpkyRJfoZuC+ePPcfLyPccd5Xyk3FOnTq2YNm3a p1Op1P8TQrS0tLSc/PDDD68kWse8Hpok9D3BQMIIOgGUjh07dkhdQ8PZ0/fYq33U2HFajGlLVqh3 obVHIHKVry/MhFDWmPDPC4EItJAzyXUaAQRCvXKPq+tUvrFbWlETddG6tMIpXuEpfylt2oqKCuYe eFB9SRCcOGzYsHpUh6TU3L4Ab+ZcCVBSV1fXOHT48H/d75DDZEVlpeJN19nnzhY5pnyd/IimszcM 2AbuBEFguItZ1YYzjyPHHY47q4Gi3Ck9FlBf38Dcgw4eUltT83nNWanmxXRO+gpf+ZaOHj26pq6u 7vgRo0bvf+ixx5eWlZdH2ySuXK5N+tyqerm2K+xRVakARIDUdfWbVF5eNQ8iEOpSm2+M19j9Ha9G 0Xu8mms1r+mSEqbMmMncAw6oGzak8WtABcpDZdqk7nv0GMkcAKKqqqoMqA3D8PFNmzZdsmTJEjPP Oa1fhu8gz3uwA39PxT6ngGDJkiUdixYtuqWzs/PCzs7Ou5qamjYYLmIPJweJCzrBQMP+EKWUNRUV FXMmT51RRUSmqC9SeoIsj4s06p52glxKrQydvI/KKT8TIHfoVijbRKBtOGlLZa02k9KN8aCGBENt sTtrQ5hBTt0BFqmAyqoq0RWGpdlsthI1bUJlrKI6Ax1cJPNYaCmgVAhRhRCjhzQOE6qc0lPCsSp6 VpvU7gKrcj3uYt0Xj+dt4c6wJpEEBM65rI57z9N5mz2L27fUPLd1kE4xZGhjmjDcBSjDaRyft16N oMa4TQOp2tra+rr6+uP2PuiQrpKyssCU2HBrlaYQuZwIwGt7hg2fvmgzzueizuVV2lsJ1Kiz1KpW uKgp07aEiHj68/JqGrLHa2lpKROnTS/5218fnFhWVlbV0dFheC3BcVzIxR/pQyxcuPD9PfbY46vN zc3NL7744lpcp9u8JG7ucxjLx1a7wH12pPPWEl66dGnn0qVL/0KUJ1O/eD0tEgWcYECghZ0Z90kD ZUKIShEEYxpHjLCdfl9AB3r8Mdrxdimd4nDnbFiMJ7SMKsjfBzV5RrLFZaSEVwgIK7MECInfUVBl MUrYZKEEnPU8GVekDEFCVzYbbNy4UQDlqB9oFhcZ7VfUZJlGKZ3S9vb2atkVVtXU12vr3zNPda3j rlHfARabJaLKHeSq4O3hTkQ6H4q70GYn8N2nPnfWpI7UXiAkBIGgsrom6OrqqkJZasZFmtLvPVlp 8cJH2mQYhnUlpWW7jxk/vsQUwe+MBBGSfA6VtjMufzssYs6L6BWRIuQT+57CFF4pbLdGK2LDq/eL UJflaZOqQ0teXqWQpFJpwjBMd3R0VKDaos9tvjYZ5zIAxIYNG+QTTzyxBNdh9KtuKtNdXjsy8nW7 zHvcpZ7FKV8hdO/QvzhRwAkGCuZHZ9xQpZlMphyJjXYW1jKLXpSTkRdIJHEuubiVIY2CtiZEVAb4 ytsXmP4Ymck5QFqF6ruadW8hIiTBCL2o5WFyllroSikDoBI33laK60F3eUUwisJYamVhGJZIKVN+ 4bUpnIc0p0qsgtDHjfs5Wl+/KkXijigfvhwSsfwtd0Y5Ge68ZxmGYRrVccl6fHXR9/hh0yZTQImU shyoKi+v0GXz2qRWVIHqFUYz8cxea+ELpxD9NunX1nErvXyielh6B6LdJjOGLO0QjB0jzn2Q9j49 8BqgeO3EcWsUcY4F7HkR4kGCfufGrxI6P5On85lHketaGfzzokBacywYOnRoWTqdzqxdu7YN1a6y 3rU5nY5EAScYKJgfZ4l+pbLZbFn0tCdAjJCIWWrC9Pw9xRFXvMaqEFL529rb21i5bBkTpkwhnU7T 1trO6lUrmTh5Cq0tLbzz1lI62tupb2hg10mTEUFg7+HkVsy1Ko0p56xbp1Sc5RHxhsbKrBVwBcoF XUY0Gtp3W5mo8bTmrqyrqyuHu1xNGj1gRKUEujIZVixbzvCRI6iuqSWb6WTFsmWMmzCRdEmabCbL 6pUrQcC4XSeAgEwmw8ply2yO5eXlDB81ii2bNrNh/TrSJSWE2u9ZUVlFWWkpGzc2WSorKqsYPmqU ssQsd0K7SjV30smoSACb6fxEa1iBcj2bsTlfSPYGfuemFCixbdJ/9J5yNBa9+mscwC43c/OO9nZW LHuXkvIyhJTIUJJOlzB21/GuPnjt3FipXsEKF1nxlenspLSs1KhU1c2xqsznVW4Lr+2o9tiBG1vP 50r1lQuNjY3BhAkTxnR2drJgwYImr0q+y9ZXvvny684yHszz8fYVeMfl6NGjK2bOnHk00PLwww8/ 6J2DAo80UcAJBgr+DzVAW3HmhLUW/PeIlSGtleEsJi3ZreCLtXERIMOQlcuW8ePzv8N/nv899pi7 N6tXreQXP/kxl119DQ/f/2f+cPONZDMZhjY28qWvf4M5+33EZh9ZbsEGeknfQ63eJDjF61/ihHQ0 KtpWohylVI2SNRZE6CfUSOm0JWEYluVwp0oQcz0b7gLLk5SwaeMmfv6jCzn6Yydy8plnsXHDRq74 yY/48RVXUj+kgc2bN3H15ZeSSqf4waVXUFpWyuZNG7n0ou9TVlZGSUkJdfUNHH/SKaxfv54/3Xoz FZWVSKCsrIzpM2cxYtQo7r/rTmpq68hms4wYtQunn3MO4ydNIh4QaoLtrK0sXQCe4c48A+G4K/Fe xkOQFUIEvRwH9oNsBFAmpUw7XkVum/S1bJ42KVHKdvV7K7nkwu9SV99g6zdkaCPf/cnP8IP77MiB iDUor0ULBFJEeehoa+f5Z57mIwcfQklZqWXEOmUivNJrXnWnsEy/2jS3nZqjMJ8b1b/d+PHjG0aO HHluGIabFixY8FN9zkytMwrXfDdKOJ5XbxRkChiD+v2g89oAbNTHJgGL9PEKYDzwRh/yL3Quns7I M0aNGlVfVVV1ObASeDD3cojzl0RBJxgomIZqBGfKCDs8IWHcaFEXZXyOr9DXOKWS28F0Qq61tYXX X13I5T+6iPbWdtrb2nhn6RKa1q/nsh9eyLTdduMr555He1s7//fzS11ewosm9gfaTD9CuFe8s+BV Kycq2qoP9ddEm/pR0Fr+20zjEZlp03mJu0IVdz4HnsDVnQQJdHR28uKz/+DaK3/BqhUryGYzvLVk MR3t7WSzXSx/520effAvzHv2WRYveh1BQGd7Jwvnz6OsvIK6+iHMe+5ZLrnwe5SVlVFRWcUL/3iG hfPnUVffQElJKatXrmTJG4vYZcwYysrKePSB+/nV//xCVS9wBmu+4Np83EVqqfzUfhS05a0PMHyb jk1Ku7YjfPpt0rmGo+V2fpsAAkFJupQhQ4fxztI3mffcszQMGUplVRVvv7mEl154jtcWLKCtrY2O 9g5ee2UBb725mLVrVtPa0sr855/j5Rde4O0lS1ixfDmZbBcrlr3L/OefY9GrC2lvb+fVl1/iR+ef xwvPPqM1gVC9xSBAWF7zVLgHXjUnZbiOTW+5FQBVVVVV6XT60yUlJSfhTWEiOkQQxj6HvTgeP18N nAdcBnwX+CHwSaAGmABcBeyjKzUO+Ekf8y90Ln7edCpkSUmJkFLWhWFY2wNXFokFnKDf4U/Sx0VE llglQtTajU//Md3MiJUg9bQMtPVpFHHEclYHg5Rq5u1tbTz9t8cZN2ECoCJqR+yyC7N235O6+nq+ ct53WL92LWaczIxbms6ucj9KjNwSKJmnbC1pA7SMwgtD0Gt2WUvH2sBOS5aRf/zM0hHjzoxV2t9u Ye7cTFx/jFIIQRBAEASUlpXx+99ez1mf/Rd1LhC0t7bw4D13M27CBMrLK7j7D7ey+5w5iEBQXVPL v/3HVymvrEQEgheeeZpDjzyS3fbYna9+9tNUVlXx3R//lObmZv540w00DhvOiaedwYamJlatXEE2 02krReC488vvonej3CkLL9IL8j0H8UjbbiFyenS2Y1OqE3TfJr1xd/+4EJASAWPGj+ein1/BXbfe wu0338QFP72U99eu4fvf+k9aWlroymb54te/ydjx4/n2V77I9JmzOfTIowhSKS79wQVMmjKNVDrF 5OnT+ewX/51rfnEFy999Bykln/nil1gwbx7NW7bwh9/dwAGHHkYgcMP1ltdIfQHytskYr3i8Gk7z KuB805I6OzvRq0VlDVVEx3qN0sp6x7YFpcBhqGU8FwJTgHOBxShLeC5KOR+J+o1N9+69rTD1NW4t P8pZdnZ2ZoBFQog1XvqAaDxH5P6JBZxgIOFbHEK7u/AjhYXxozmvllVWvuPGGXV6+pEZFy5gTVVV 13D4scdx6Q8u4I1XXwWgtqaW4z5xMg/++R6u+PEP+f3111FZWemEq0C5bvOu7SCc1eFXTwDaChXC d1FGlbceM/b58JVvPiXiB7YEvgJGj6m6gCp3T+GS2DIaiqpravjYyafywj+eYf7zz9nsNm3cyMN/ uZ8TTzuDoz/2cZ5/+u+0tbYigJaWZu685Wb+eu89vPLiC+y59z4EQRArrLp3GEpWrVjOH2++kVtv uJ6Vy5dx0hlnubQRV72IWPM9cedx4kfZbqsV7M/xFIawbttkzo2CHEWMlCiZDF1dXWzZvJmVy5dz ytnnUFJayo2//iXt7W1s2byZ8RMmMGPWbH5x8Q859MijOP/in/L+mjUsnD+fl55/juefeYqzP/t5 qqtr+J+f/JiTzjyb2rp6vvSf3yTQ3oSeeO1DmzTBfj21SWLHRXt7e1sYho9Ita1nXPka69FEWG/v aytqTebfAtfostbhlH8Fat9g870Y94yPX9v35cuXb2ppaflBa2vrLwpwRfx4YgEnGEj4P2Tz47aW BOhuZeBiG+x4r2dtODeguUKYJFhBJNztBFBdU82Zn/o0zzz5OP932SWUV1SQLilhn/0P4PhPnMzm jRu58dpruOyHF3LAYYdRVlbhfikiGuOs7ipVIJa2uEMzlOYmbUaDYEz1dZSMyFUivvLoTtDlUTRG kIrYYiWu/L6lZiyfispKjjvxZFqam7n8xxfpsdoMK5a9SzbTyesLF9Le3kZHRwcL589j3K4TkVLS 0dHB1q1b+eTn/42PnXJqbnGFKahUHZ+jj+Xdt9/itYULyGQyqjwmdFo4a031qdw4enQ5RcedMBW6 IwAAIABJREFUx4e/MEJ33BWCiL0C64Iu2CYNpcIkcxW2380xXylKOtrbKSsr4747b2fNqlXsMnYs AVDf0MDX//t7rF61klQ6zWFHHs2IkSPZa599WTB/HqtWLKetpYUnH30YgJG7jKayspJUOs2IUaO8 cV4K8uor4V60ydwOSeE2Gfn+yiuvbMhkMl/RO3BJosrXV8K+Ner3cHOsxDz3NPmAcjs3ArNQY9aP ocaGtwB3A/8LfE+njSxF3kP+hc75MNOzUoBct25d+yOPPPIYue0K73NiAScYFBjFYT8bC1jEBJhz h0kbVGJWkrJzRX0FGxmj9eKotYLu6OhASklFVRVf/875dHZ2EoaSNatW8ZMLzufeO26nuaWZaTNn MWzESIIgpawDq+yNOtGWuP1jjhsryS+zdEPEEYtUpSsQh9FdrznfjzmHO4c4d8o9buaPGkFcXlnB 2f/yrzQOH44Q0NLcwn133cGY8buy+9y5zNpjT2rr6rnjlpuQSGrr6vmP877Dt777fU49+xzKyiss R0EqRSqlDNJQShABDUOGsO+BB3PYUUdTV1/P8nffjXDnpnX5JSdmzXs8RkVjXEH0Rfn63Jp32yks 3CZdGXOy0E9ESuUpWP/++7S0NBOGXaxcuYKnn3ycrVu38Lkv/z/GT5xIZ0c7GzY00dUVsm7Natpa Wpg8dTp33XYrz/ztCR576AGqamoYPnIUdQ1DOPG00zn0yKM46PCP0rS+iUymk4Uvz3ftqRteI22y AK99bJP+eT+NeO2117YuWrSoxaPJvPuWYyilNC8f8e9xhF4QUxZ4CrgLeNq7BygF/CtgFXCx46F3 +Xdzzrd6fYUe69XkvOflMbGAEwwGCvaqpVSLLZjTEUtDiNyLhLFGtcURs0iymSxvL1mCEIKnn3iC 1tZWxk+YyMYNTby64GX2mLs3t95wPbfecD1V1dWc9dnPU1pWpmcXaatBuNmbxo3nK2SzkIG14LQ1 aspt3HzO17f93Fn3vRagMmajR8d8PUokLFm8mPXvryWTybBg/jzKKyo4+PAjeOi+e3ll/os89fhj fPzU09lt1mza29pYu2YNTz/xGAvmzyPT2cEr8+bR0DDEKw1s3riRrmyWzs5O5j37DG1tbaxetZIw DJn33DNs3riRMJRsWL8u6voUgtDILTv/11ZC1Uwfzw0asiXYHla7s/BUsXLaZOzWInpxNpvh7TeX 8OI/nmH1qlVUVVXzxEMP0rx1K6lUmksu+C4IQW1dHS8++yxV1VU8+Od7qamr4zNf/DJXXfpTbr/5 JhqGDGH4iJFMmjqNmtpaLj7/vygrL2f/gw7mmScfo6amlj/fcTtHHHuCKp+kmLzG+enufHfPwCim iLLylOi2QqAsz6eklE8IId4GPg8M89KsAb6Kt/NSMSClVLtJRTsYEqCxsbFMShk0NTVl81yaw1Gi gBPsMIgHuuQEYhn3bkzgGcvSWqaB68JnMhk2b97MRw45jHnPPQvA9FmzAVgwfx4Ax33iZKSUlJaW 0jhsmJ3aG7mJVcieFRw77lub6pCxNAVG/hQQO4JcQdY7xWKUvxC2Y5CbRCCkQGpeHvnLfWQ6O5k8 bTp33nqLrdWUadN54qEHmb3nHN59aynX/99VNrtJU6dx7x1/ZMqM3bjr1lvyFmVIYyNI3HUShgwd ym+vvgoJTJg8mY+fdnqO9ej7FlSHRUSsdn+q6PbL7d7BLj+Zt01GLV7z2SSTUtLc3EzT+vUMGTqU fQ88mPXr3gfgiGOPi1ybzWbY76BDWLd2LVs2b6Zp3TpOO+fT7L3/R/jyp85m7n77A5K99/+Imj+t FW3z1q0ccdwJHHrU0do9Ht+rqy+8unbdC3SbuK6uLpgyZcroTCYjFyxYsMrS2Ycb9FgA1busAlqA YUKI6cAo1JjwQcD7qOCsqSiL+FnUgjf9il133bVi2rRpx4Zh2P7II488SH4XewSJAk4w+DBWnPRW joKcoBEj5PLYwVoPujRmtanaujq++NWvEwnQ0sJP27dWKcaFu7MrnYK1947N9/Vu7JXIKEV/ZSxA ikg9twvClc/3HNqhQI8T7dvlP779HSwDRsFEvAsiqmigz9zZc3ZYQFpuzFQpR5Upv1Vh5OfOjGV3 y932WsQqE9Op67FN6jhzzS1AaVkZBxxyKAcccpjLy/AZexbmvP4Q4fXh5+dbXvfaZz9bADcE4nf6 it4mC3UK88HeYeLEibWjRo36lp4HfJF3rphKuAQYCbyIGu/9d338IVS083Tgb8CX9PHXgOdlL9cI 7wMidRo5cmRDZWXlFSi39wPdpTVIFHCCgUD3lp1nxbllDb3FDeyxQlkXyNy6fYMchRK5XktEETsf 6vvmt7p8ZeEd0UaGL/fsIhN6UFkS9lYUxQUgxAOwrPvbMRDlT7nDXWyYc4+rY1F3eYQ7m4+vfGPF 65Y7aZUt0tuRR4siu5Ci14lwY5lGmXjKWUYVeR6u+oJCbdKjqac2KUEGavqt06peVm4BFH2V5TrS IcwpvlGcMq4U9YLMHq95KcjfJreR154QuaqysrI6nU5/Wkq5AvhBT+m3ESGwFpjXy/RZYHkR7tst UqlUIKWsk1Ju6e01iQJOMFhwkkqg1te1Al1BiYfoKk72UiO0RTStUjbRcTpjCVpBGhPVphB2lxip lK6SqTKmWXVq77hJaxS1UtoR00PfX6IGjHMdhtsKa10JJ3zNZhFIesmdFyGNiHR2TCCZfzk5XzV3 oXFvGj5UBv4YuV8GpOHOm/Jjo3VzLWqjMzzu+qp0e0KsiCai3uMW0es2aQps4hP84/ExekmU5ziv lh9ivBpeILYMZW6bjHQcUFyHYV5etxl55gEXHTr/xfq1wyCTycTnAfeIRAEn2CEQYvZG9UWas7B8 S8PIGTv1RrjpN8oRqy0Nb+oFOAEXt9YcjBr3Ng3w/grh8kLgFpHQykQIHf3rC0atZKQ39UMIQSCK MwHBOsZj1lKcO7uJj1YSEiWwRRDt9DhDzikJ3wORlzubmXPZ+u+mM+A9NTfFqCB3IqJA/HoVzX3f A/wBCO/uRWuTfufGRH17zQu3trMrQQ6v4Dwa1rrdtjZZDF47OjpawzB8RAixfrsz28mwbNmyTfX1 9Rei1s/uFRIFnGAHgxJXJnrYCiBjNIExAdR/Kw/17qhGhvjjbvrNm6Jr06CvNXLLHJaADN2UJjxh bFzIZuzMKGlrdbi7OoHqpzUuvyLBjVPm5873BkitLEWU0ALc2cu6584qWMed9WjqA0KbbtLez3Fj OOmOO+W+3y5XaZ8QHfvtXZt0i8LYTHrVJtXHuLIHn6SCvNoShraD5fdZ+tImtxGRIi9cuLApk8n8 R75z3RzbWSHw6rN27dr2hx9++DHyLwgj8hxLFHCCwYebauSLiOjCG3aBAd8aE26xBIQ3LcjYD9IT eMbi8NI7veQsCHt7afKXThFbCWg2ZteL5Hvu07AbBWGtab8c24meuNO2l3YDexZuQA/cBS5vc9xT HvZuJljJrKvQLXfelUK5Zq0L2lh13VaWyEIn/Qmz8Ea/t0n/HkLoXbbAjJVIE6nchzaplLDXJrvh tYht0nYzFi1atIXonH/zPgBdp0GB6MV73ronC3EkGHRYwesJCmMpqaHWmNDV7jKzuIC6QCXxF0V0 VpwxFbxzJoEQ9pehxasrg3HpRcYA1cXGGrIBLULZdaIbEeOPwxXLAu6OO1zRbPlV2XvizoybOxPL ZmnGxn0TWbpIYFucHrizRzyzrTvxb7nzb9KP6P82ibWJtG71VrEqcpvspp5FapO9tXQ/SNZvXjQ2 NpYPHTq0rOeUCokCTrBDID7W5SsQ9SasoDGGlrNgVQZKkDnRJaURpMLdI6IBfI1hbYGI8LPf46LD K55TW36Z9TibsTGkE+DFHsIsyF2sTMb67Zk79Bihpzj0PYTPXfyOsTHonriLX+vSFuaO2H36E/3b Jk0SoWMCRIw/Ym3SeB62oU3aA/3fJuvq6oK999579B577DGiODnuFJAAEyZMKJ87d+6xc+bMOcQ/ Tk6Ld0gUcIIdAtJzmykLzJleqlcvrQJRKXyrTGVgRJTf2s3YqHYAYlyl0rtUJ1T3jVhiOjDMTo0R vizzPK4yYv3Zgmk3txAQD3AplgsaCnOnBKxboMTMje4Nd443owSkFt7kcodWVtLXIYW4k8bgtZkI TZ57voW5KyZvPaFPbbKXvILjViXNz6vr0Jg2aZRkH9ukX57+a5P2DmYe8JgxY/7NOxdJ8wFCpE4j RowYUllZeUV1dfV3ya1r3vonCjjBDgNfeBs3mhm3FZ6F5KwKv3dvYlbd9KGYl9TcRS8DL30TABUg pBbv89MKAdJYJ75F45k7fmSsL22s8DVWhrk/xZdEhbhz93VqwKfCnIxzZxWEochkEjq+fP4sM37m Pncmhd9RiWgO8nIXmmflnRtI9LpNyt7xmtMmC/GqP0vCGG99bJOy39tk5DIzD1jvB5wvyw+aErYw 84DDMKzp7TWJAk6w48D7aRrl4cbdYhaSdD1235pShofQQT357qEXMYjf10onJyQlUslFiRKQ0jod TSkRqGke0qzaocseT2mtEaLTP7YX8U0LzP3j3AHKGjaC1yg+ayI5qysvd1oLSC8/d9x9tIelThdK p1w8VWA5kiptIe5s9K937UAsR9lbXqNt0vOeeO202zYpsfOk8/OqPRHxNglaK+dpk2Lw2uRAzAPe UeHNA17a22uSKOgEgw/TSzdRoMLMIw2sALZzV4UvEr3rhZs6I6RaLwj0tZ4FZtV2RNZ1gXfMH6ez J4SzgIwiMlBRvOYzVkC7ennHbHmKA+O+FF6+hbkzCsMSZQOKnEI2SxPmchdxURolFOHB6GnPxLXL Hvop8K6RdgGUHO7i2kp/HYh5wDIMdYS3MdL71iZN7IGZ7t19m8Sec50ZL6qcPG3SG++Q8TYp+9Im dZoicZrMA07mASfY6eAs2ej6FJ7Y95SHRGjfjbYAjOzQQk96vX6VyluvV0knosIvYgjqa7W1EBoh KLD7ywhdDms16KkhJrhGYAOYhFU++lvMDbndkL7wtKrY1QPw1yuWVls47hwtqiODM5wi95HoubHS 7rPjKMunKz0rrnvuQt+Q9mAsRrcA40AtwpG/TfaNV/RXIKdNWpiOjmbAdBLt6XxtMuLv1plsc5vU ddx2WiNXJvOAk3nACXY2CDdm5YSBc5c66DWdhfQimm0WRvYBnqVnrTktvGM9/8LwXLe2DMbSwFls 6LnAev9xqe8V1e6enSO0JbP93j5bJP82LphWRzEL3PQWXRu7dSOOd9dNiXIXWSLSfM81ZP3KRuqY w503JmlpkvYhedwJNQ1KSuxIZbG56w5522TMCiXa+dkmXoOYJazbfH6FKCPKNxq1TsE2ac7baV/S XGDqUBReTYmTecD53/PWPRkDTrDDwJ8y5ISQFWe4pfe0ivWsDDen1BdQ7q/NvxsRIKUk9F7GLBNO ajmdL1z+SsHpBRO8YlnYAzLPseLA5y5nLBFPWEtXbqnTuvTSynfTkYnk75m92WyWNe+tonnrVns+ h7tIITR33lCBu4dOnI+7eEX8ugwAemqT28arf4PYK37Y41SazoiMp+q+TdrfgX+P4rbJ3lq6HyTr Ny+SecAJdjo4YeUpunga/ScihmM9eRm6ABmXxre6vO+xVxixzKLCKjpv0ghDVwYjFKVJBLYzEIZE ymROFy2QSHc+3H7AeZPglsx05XYdChMM5V8kbX3zcdfSvJWbr/s1r77yUow7MMOXUQXuc2csuaiC j98rDM24pleWYvHWEzxe+9wme+TVi0yOtcNC6czzQHsg3Mi/aa552qQtY7RNqjJFrWNTlu1FMg+4 b/OAExd0gkGH765TUP1C3/3pjYrh+5Eju/d4fmjruBSB+mwEZXd98BwB5BSCuVRa16gO7rVjbkSF cWTszV3t8iqeMaAEfW/2rdXlMILaWHE6Anfrli0sfWMRIggYNnw4Y8ZPYEPTetauXk0QBEyYMoXW llbeWfomrS0t/P2xRxk1Zixz9t2ftxa/QUtLC/VDhjBh0mQ2rF/PmtXvEQSCiVOmUFparvSSuiGh tFra1sL/Hh2GUHVRdRJF5a4nuDH73rRJ9dnnVZeeSOMQ3lCGNy83cl9iytM7o3SwGQpxZwR52qQ9 48opbMR10dqkvdkA7Qe8o8DUSYCbB0yyH3CCnQlKQTrfbkTI2V67ViJeOvVfekLaE85W3oXRIKX4 lty+zIn8PNzvxXkSoxaJClpygtUoFzftR+VjlbAniorlRrVjpsK/n6+Io4LY76z4QryttZX77ryD 22++kaHDhjFi5Cj+4zvf4cVn/sGN117D6LFjOfeCi3j8oQe47093Mm78rmzcsIEgCFgwfx6/uPiH pFJpKquq+Mb53+O1Ba9w43XXMHrMOL7/s8sYPmKkUxhaqVkL0hpojrswxLPoZb9w1x3ytUnTmSnc Jsnh1Spq1S/UzypEGOejNDa+g2e7Ev9obFunZ50trN5jbdKmlRjlXeQ2GblogPYD3iGxLfsBJy7o BDsOJNoVVyDoxUlwjFC2yyVqQS6dNI9ao8atLMAu25Qj+qT+F2Jcen5ZTBo73ibBuHaduzYqX1yZ pHNLFlEGRdYkdhVWdZHG4skv1NUOQ+rr+rXv85urr+Qr557Hdy/+KS+98DwP3n03TevWsbGpiSOO OY6uriy3/OZavvyf3+Tsz32edDrFls2b+M3VV7J50yZO//RneP3Vhfzu179i/fp1bGzawEePO56G IUMj5TK8+HrVcG/rJZyy8CF9jd2PKBav2OdvM8ZrMLn2Ydz1bO5JqF7x6kfGzc0Ysdcm9XE3dt2/ bTKZB5zMA06wU0Jqd5zIseaMO1X176PXOLew+m4Ej7+Ob2ivx+02Y66WIHLMYg3jOdSSzAipEKkt ac/68Lx5TklEXcJGHBZ1GUry7RlrxoMDT/g7N791RevSh2FIR2c7ZeXl7LXvfsiukJraWt56cwmT pk6jrr6eT5x5Fm/881XKKyo48NBD2bx5CyWlZXRls6xZtYr2tjb+9ujDzJg1i7IyFYNSV1/PKWed 7XFieDJKxauHdPVRSig+RulxNxDzgIvAq80HtSOR3X8ZV3sR6YUE2C9+g/LzjXdMvXapaA1das21 lI7X/m6TyTzgZB5wgp0NUqpFDyRIPbdSddijY1eYv0aQCGEFpZlyY1yATnu6dyvnrKzxBTxx2alW EoqUQG8PF8YEmcsqXi0L4/LzBWdRkJc7V//oOso6vXXf686KCKiqrmXI0Ebuv+sOdhk9ls2bN7H/ QYewsamJqupqgiBFXX0DNbV13H/3n6iorKSttZXS0jLGT5xES/NWTjr9LP654GV2n7M3i/65kKrq 6qiVK6TlznImovx4FYt8jiicgQjEKgKvfoJYkyPnq1Xi0h2XMn9bzVP/eFv1P9iFVYQw+tkeL0Kb jGjuZB5wMg84wc4Gs4KTL621dPCDcZyQVoJJ79iqLzAWrlmf18y+lDbviFsRJ8ecu1vn4y8hhLOA Q4H640lYoc/bCFSUEeJck9HoVlemIimRbrkzY6re1B/913GnjtQPaeAzX/gyd956M0IIDjzscD56 7HE8//RT7LH33ghgSGMjp5z9SR598AGQsOc++zB91iyOOfFELjz3W9xwzdUMaWzkE6efRfPWLewx d++o5RsaF6h+rsJx5yzfmEvViwfAKsMBQJF41Xo1Nv3IOx+x5p1XwKxk5Y2oRLwtbo66f8Jvkzo/ 487Wf5wHPNomfet6G2GuTuYB53/PW/dEAScYfIQSAud+Nm61XIWp1xC2rmW9M4zr4itZJKIWr1PR nmXsnYkLOX/+poVARQZ5h6UtJ1Yyqt1+ouOX0TE2rWi2jalc6J6Jz5Ubt3YmZkSRGZeo+S6hvKyc o074OEcefwJd2Swl2o185HEncORxJyClpKKyijM/8zlO/9RnCIJUpBjX/eF2wjBE6KjzI0YdzxHH Hu/oCp3pZS0vjxM39JA7jm6Uh3k2AyLF422S3vEaCYSTRuVh24gdTskxOqMK2Ri0ftv13fS2TdnF yl0ZXSqVg0rZfZvczilevbV0P8hKGFDzgKWUQVNTU6/GwBMFnGDQYccFvZ9n7liwEnp2bNAuyBsV YSoq2gg9vRCBWQbQZajTe1YK1l7NFY72g5veZOwP30No5reqo/revntPFF/6KHpi3HleA8Vd9LvT KbldFCEC0iWlGF9lhDvNTSDcGKivIISxEF23xI6Vm78+d+4xCsudrVdcGdi8BwZ522SveY3Yq7od q5NChm64BCLtB1Sn0j9uVaSxeHVMhFrpikj54srcdlxC01K7aZORaVXbjrq6umDKlCmjM5mMXLBg waoiZLkzQIKaBzx16tRjwzBsf+SRRx7Ee3yFLkyioBMMMmSO98vtcuQJaal9lt5lfs9dyUpjDZg9 fwXSPyqlFXAuE/c9NFaWILZKk8szonB1Gf0y+IIuAuM2LOoYcJQ7s0WenRcMNogNnKvddBb88sfr 2VfubA72WcnYK1ZsE4gl9YIbtt8TtQTtJWHorON+t6G2hVfh8Woi6KWprHoPXcfEMpNjeebhC69N 6rxUMKFd5UWXE31v6fFrcvM9EH6woy7f9tFqC53sB5zsB5xgp4KwvXBnQUot6HwXsRPmTmHo6zU8 WeIsQym9LfHUyy3thxWU0k8nJcps8ISnn7+kgCIwCszrPGihHV2WsFhu1Ch3UiolFcoQEzLkK9cc 17p0/PWKO5mfu9BL17J1K6+/+gqZjo483HnjvTnw0zpurdIVZnOBgZDiveNVCJ9Xr016BYxwqg9I 8NoaWjfnb5NuaU/92/DfzV29dulu5LZ6NN4jVygIdZ3MAVXHbSIrclWyH3CyH3CCnQrOevShOvvR 8UDfgvStBpdOWwf41rD3stIwetxZK0TS2RTutl453HdlwUVXdhLCjrzZbPWJPjNUGBKn6F3eljuZ y12ca1fGbeXOkdPe3sbjDz3IReedS3Nzcw53dqENqRSClBCGId7alZqi2LxU76NyTPS3DO8dr7bd eJ0L59z3uYtx6rUVx0++NmmOm86gy9lc63U/vecttLfCdzm7301OB6iIbTKZB5zMA06ws0FLEilF RHy5MTYnWMw4mxXqwkR5SidIcrR5fNlAcGGp0t3PK465nSuNu9TXCGG+KcRSKza/HEKqtap1tkUT eZq7UAoCw6NwU2ZMGQKhXMrOAaodlvGOgZRkOjtZumQx6XSa5q1bqW8YwviJE9m0cYNeljLFrhMn 0drazDtLl5IuKWHCpMm8v2Y1V116CXUN9ZRXVOg75XJnFItTWLGOgveuEOpxzKhC7FcU4tXS5PMa H1Mnwquw6d3YsAvm0scjTdYpTPumOfObuPHCSOlfZ/pI3ji8PpXTJpF6+pL7XW0vknnAyTzgBDst nNAQEcGGPqZTSRnTtTHREZckEreugc0nV1jm2FU9GFqmHD0bZFIbI0WfhAQeT5HZU/ExVP3X9FNc mV06c8mGDU1c+O1vMnzEKLZu3UJNbS3f/v5FvPTC8/z+N9cxaswYvnH+93j8oQd59MEHKK+o4IST TqFh6FA2b9rIiFGjyGazBSsphPIaqNWuokoiEp0rQU/ExVjn/W37+oXMy2sM+Xn1LjB1yHud+1ZI +eWtryx4JqKoZSxdtHtryqYSbodrP1L0ZB5w3+YBJy7oBDsU7HSJEJzL1Ass8dx9NuDFXBsbN7MO vTzuWBP8E4YycncnhnLv7b+U2zk+Hg1mrNAE66hj6IX5pZOdxXKj2rFAGfEO26ClAtz5rkwhotxl OjO8v2YN02fN4lsXXMi7S5fywD1/YsP69Wzc0MThRx1DZ0cnt/3ut3z81NPZe7+PcOO11zBu1wnU 1NVxyBFHUlVV3S13viVsnwkyOjYpos/Yejr63QWdy6vQy0v6vJpyq44DmOCz+LCJ4dUf+zfHjVQ2 1ZJeuny1DAtwasapI887D7fxY5gybX+btDFrixYt2rJo0aLm+PHtyXwHR7yOhd5zkCjgBDsOrADI M07lITJhQqKDczyh4ykiK12MCy6vBWoUQlyA5S9i3LKI3it62Bdq/qeiqxBpFHxu2SOrNpkFJqS7 JvTnkmoLrrKqihNOOpURI0cxpLGRFcveBaC2rp4TzziTzo4OOjs6ePnF53nrzcU0DBlCGHbROGw4 DUOH4sMpF3I6LKZTEH+mrpC5vtEBs4JtGSQhYcE2AVFL2D4LGWsjpm16bdTf2tK0C++raosxpV+o mPm4NV6FyOPNKXe+M31Cby3dD7ISBvq+H3Digk4w6DCCpdCvM9vZyapVKxk9dhwl6RJv2NAfxxWx d6f7hIBsJkOQCgjDkLVr1pBOpxgxUrlK31+zhtr6Oqqra21+yqVopJbLz5/j6hlqANrCiNfLG2eN WE3FUSMSIutbW3g++vx3EtbyjY6zq1xbW1q45/bbmDF7Nu+tWskpZ32STRs3quUlgaqaasZNmMiR x50AAt5ctIjqmjpXKDzu4h0WeuBOgNSDvjJ2QU+KqFiwvMbHm2O85m5kIGIufl/F+Sfizyd63Bw1 86Qdn9GxezMO7Dvp/WLH2yTGoxBvk1AUXpN5wMk84AQ7IeIRpqBldyjZvGkzv7r857S2tBBty36P X3quvKhF3NbWxnNP/51VK1fQ3NzMzddew22/+y0dHR00b9nCjb/+Fa8vXKjdeKHNL5+r2ReWbgMI z2K3klFFrsYFnbquiIZATIDaLklo3M56TD1S7vhoapQ7UG7oV195mbv/cBv77H8Ahx59DGPGj2eP OXNJBQEjR+3Ciaefwd1/vI0H7rmbxuEjqKgsZ8as2TQOHx7hLr/8cRZ7vC7oKTE5yld/HRAzKtZZ yuHV7/yZId8Ir2YmtTGIpQ54MvmqtuZqlj80L9TuZVcsb960aes5fh1pj+fkqNukMHWSCJSbAAAg AElEQVQUfvvYZtibJ/OA+zYPOLGAEww63JifEwO+YG5vb+efC19h6RuLCIKA6tpaJk+bTjaTYcWy ZWzetJGSklKmTJ9OSWkpTeveZ+Xy5aTSacaOH0/TunV875tf5+Qzz+bUT36KZ5/6G22tbey1z35M mzGDF/7xDBMmT2H3OXNZ8vrrZDJZamqr2XXSZLZs2sTaNavpymYJpWTkLruwavlyqmtqmDxtOp0d Hbzz1lu0tjRTV9/AhMmTseOt+eqqKlw0K87nzrP99Umhg5i6uQ5txcUC0+qHDOFnV13NkMZhCKF2 6Tn86GM5/OhjCMOQ8opKTj/n05z2yU8RhpIgUH35717805z8/e9mHeW89TdrLOcrb4Gy9xfibbK3 vJprTRx6PABLKdCQTRs38u5bb5FOp5g4ZSplZeW89eYSKioq6OhoZ8KkKbz15pu0tjRT39DAhMlT TQ4UvLFfbql+Q8IGWfkdSFzd7BjwNnMauXCg9gMWqlE2AjOADPAa0AbMAlqBCn1sJlADrJdSvl6M exfCtuwHnCjgBDsOrDs0tApFLf4MLc3N3HTdr9m6ZQulZWX86PL/YdOGDVx56U9pa20lm83wmS98 mX0PPIhbrr+O5555irr6eg476hhGjxlLJpNh3nPPcvxJJ1NeXkF7WztX//xSLrny/6itqyOVSvHO m2/yw//+NjU1taTTab5z0Y959eWXuO3GGxg2fDhLFi3i46edxvznnqO0rIwfXHo5q1eu5KrLLiGV SlFRWcm3vnsBY3ad4NUJbdwIY7IUVYGIiEvUqWCh/7hbCbsVnh0XNNfpy0xeJSWlzN5zL1KptE7i trjDKBbrxhSkAl9J9QCr13RQk7HupM4zntYPKB4g97MtH0R4td1DAVIa57ObmuSX17qQyVXgzVu3 8qfbfs/jf32Q8vIKPnH6mex74EH84NvfZMy48VRUVXLSGZ/kqkt/SiqdorKyknMv+AHjJnjtChl5 iyMSYBUqazz0Lo1sDuFb+9uJAZwHXAt8GTgdpXCvAx4BbgGWAs3Ar4Gf67I0CyG+IqVc0l8F8uYB r+ntNYkLOsHgwghef1Awj4s2FaSYPH0G537/B7y3YgV/f/xR/nzn7TRv3colV/2SY088iasuu4RN GzbwzN+e5KDDPsqBhx7Oon++ytTdZjK0sZH9DjqYmro6JHDwR4+grr6evz36KKWlpWQynbzz9lJq 6+o54eRTeOetpTz71N/Y0LSejvY2vvj1b9AwdCgvPf883/ze91m1fDmPPHA/N177K7Zs3sQpZ32S xa+/xh9u+l1uBb1AGtDCvRh+VF+BGe7IzTq+7KAaAzTlEV5e6jkMHTaMi//nSuoaGqyrUyeJuTrB uJELxe36EdjGKjOdENPRArzlP/F6DXkCkIrFXXfweY3fL65thVNcJgAuOowSDexTMQir+eNNv+Nj J5/GnP325ze/vIrmrVtYuWI5XWEXJ595Njde+0u2bN7EqWefwxuv/ZPbfvfbnDIaPiP/YlxJKZFm rjyuYxZvk+7k9sHMA5ZSPr39ueWHtn7HAv8J3AA8AXwfqAMmASngGuB8YAjwS2Au8M3+KhOoecCt ra0Xtra2/k9vr0ks4ASDCx1kYiwc881t+aZQVVPNyWecTWlJmtr6OjauX8/iRa8zZfoM6urrmbbb TCXgZMiU6TN4+cUX6OhoZ+6++6vrq6oZMXIUSElJSQl77r0PHz32OM798heorKriMCnpaGunecsW HrjnHgCCIEAIQWVVNbtOnMSRxx1PSWkpw0eMpK6hgfbWNtasfo/2tnaeeuIxps7YjZJSLwAyNnYZ cQ8Ww5IzATpmUE+aXYXMfrvSriolpN3NmEB6XlSRu/F8pNB2zNLcMqrlXQBd9Pqc0K9YeuOiF2GY q7rzTK4uOnfdwecVL0Lba5N2nrrUPgHTmYkoaHJ4laGkraVVRZDPe4GubBf1DUPoaGunoWEI515w ISWlpax97z3a29t46vHHmLbbTEr17lSFo/NjFrE39h7tLuEsY++799ZXRCo4QPOABVANlAOHoPTY OpTbeR3wH6jFMMYBlcCJwEtAexHuHS+HrU+yH3CCnQ/SRJsCZrqEsSoiqwhBKp2ybrSqmhoOOeJI br/5Rl549h+8+tJ8xowbTxCkCMOQk886m1dfeZkXn/0Hp33q05RXVLBy+TI6OzqRYUgmk2HKtOnM 3msOby1ZTHtbG08/8TjTZs7kwMMO57KLLkR5lCCVUlvvlZaWUVJaYiVVOp1i3K4TaGlu5oSTT+X1 Vxey3wEH5UoybZW4TkWRFIjPnbdahLkXmjtz2rMr1bxWz1GKZ42aQ+Z6UDsgRavkWfM4Sy9nE4V8 XOAityNsFFC60tYxj2LvDxilqtujGUu19TOfkWp3IpxkdfWKKWKcJ6KqWkWQH3Hs8QghePONRdTW 1QOQSqVJpdKMm6Da1cdO0e3qoIOjXNrPIvo95sovxK35bgctpNl6Y5thKRiA/YAlsBlYDNyuv+8J bNDnM/q1GOWq/i2wL/DXIt0/DtGL97x1T1zQCQYdEiMPpHX/WXeplJSWljJrjz0pKSkhXVLC9Fmz 2XXSJI449ngmTZ3GLddfy9tvvsnnv/wVqmuqqaqu4oF77mbNqlUc9NGPMmRoIwccehhrV79Ha2sL M2bNZsTIkdQPGcJ//fDH7D5nLhOnTOWkM87i/TVruPsPtzFzjz2RYciIUbuw+5w5BEHAiFEjGTZ8 BOmSNNNnzmTi1Gl89bz/RkrJ7397Pe++tZQx48erOjmva9QClsWTQjnckevytOrQd4uidn5yOwW6 QnV2dPLPV17h5RdfYPHrr5Pp7GTZO2/z/trVZLuyvL92Ne++vZRsJsPbb77JSy88zxuvvUY2m7WR 0+ra1wi7vIjyMHRRwFLGVn/26iMdd9gdhxyZvsXWn/A5Vd89XsMwx5RRxZOO17hdrxW5akej+Pgp p3HP7X/ggXvvpnH4cMory5m1556UlJZS39DA1//rfMIw5Obrr+WdpW8ydtx4a/07lzee+18dcfcv VCe/IxZtk9vBam8t3aIMHkg1PrAc+A3wReAzwCrUuO+zKOt3PfANlI77DioY681i3L879HUesBio oIYEH17oMZtSlMuoEtUrrRs9evSMI446+obPf+0bKmFgInm9ACx1vbWErYVl3JRCkMl0kk6VqEhc PWTX1dWFRFmv/hJ8PU0BUpvKu/uqg1rgmWURhYwqAyEIu0IV5KS/WzdfActky+ZNXPvzn224//77 vwa8j+q9b9GvVqATFTwSAGUo91oVUA/Ujxw5crejjz3u6s9/7RsQmPAo99cPYotwF6u/f022K8tr r7zMhed9i2HDR1BZVcW3vnchd/z+ZmpqajjnX7/A7675JdlslhNOPpUrf/YTWlta6Orq4lvf+z5d XV1c+O1v6murueiyy2loGOLVOz931rL1uYuMo4I/23bLpo1cd8VlTffdd9+/oQTtRmArSgC3A506 EKggetUmA9+xHuU1px0V4tX32Mdd2Ma7EAQUksNhGNoI89yTMhpMhczpm+SNRo+1SfO3l20yoxWg 4TClXwII6urqSmPzgEOgS7+k+S5lfILytkGoByG6y08IERTrfn6euLoDpCZMmFA9derU4715wF2o +pq2mFP3xAJOMOiQoDZ+NzLYuGlNTz8eLOJdp8Z0SxGB3n1IqmX/RJAiFaT0+JzbNzXqxjOZmO+S QKj7C2OJayEnhZ57iXnHE2SSIPA6DcbNau9hbBVtwbjSF4U7fLo87qTHXY7CkF4a/a+jvZ1XXppP NpPhxNPOoKq6mo1N69lt1mweuu9e3lu5ggfvvZtZe+7JQ/few6aNG/nuTy5h5KhdePKRh1kwf553 bRVrVq2ywVX2Ph537l3mcOeej4vgNXNb+z0IC88xYN0YMV5jnQR3YYxX6dqkDL3dpkLpOpb+jh6x NhlRvjHvhmqT/svd36S3A4/6eL426S1QuT10SRj4ecBSoVvlWmzl62eNV6dkHnCCnRee0jLK2Gzh JvT4Y97xRCHcikX63dm7OGsL7PEwlBHLxo6GRrI31oQ7bsejY4rCjvbFlLy5PvTSuOlIfWaoIHxX c6+5i5UdKSkpLWHGzJlUVlXz5ztvp72tja4wZNZecxAIHn3gLwxpbGT2Hnvx1z//mTHjxjFu3Hi+ 8LWvIUTAurVr7LVtbW20trW6+5r3uHfA+x7vHBnnaszI6wcxnh9u/NyMszpeycOrP9CXG4GjrH9n fEqEHXaX2ssictuUK02kLQcQaVeRfiTeWHS+jmfsWp1gW3mNXDVQ84B3RGzLPODEAk6wAyAiZqJd ZmmsuDBqxUnPgtDfzfF4HuaTtRJix0PveLwMxI779zDWRXzc1UQkR0bnjPXmWUXFgVcTIQpy5xI5 S8i3jAC6Ml00rV/PfgcexMdOPY01773Hc0/9nZraGmbusSd/uu1W9j3gIKpqa9hj7lxefeVlnn7y CX7xk4v5+2OPRq5dq6/NLW5Uqcq8ytdjznLlFMlAD5vlbZMyzFNmcnk1hrNn/UeVqlOs8bba2dnJ ktdfJ9vZmaMf3ei61/51ecxvwle+/rxmkK7devcrBq872n7AQohSIcReQoiS/r7XtuwHnCjgBIMO t7yfOeCECTghY5WcfyzPcesGjOWTc994enKFWUQ4effx08eFlxNsRO8v6bY82wJVLM+tvR3cpUvS 7DJmLO8sfZOH77+PfQ88kFPO/iRV1TWc+dnPse+BB3LSmWdRUVHJYUcfy/gJE7n9lpuobxjCyWd9 kl3Gjotee9bZOZ0TnzvDFXm4s88hpjgGCtJrE4V4teXttk1Id71OYz5LlCL1Fpq0nTYJbNq4kasv v5TmlmZ3rSug4y5PpzNvm4yl8xeHKdbyqAMxD7iPaAQuQ43x9yuSecAJdk5oN5wxHu08TM9WUiv6 eUJMQGQvWX/uqC+0vePSJo1N3TDoQTnK2H1yxu5ilnxE6Or34qsQY+Vojix3Dt1x53ORTqfZfa85 XHXDTWSzWdJpJx5mzJrNj674X5t+l9Gjueq3N5LJdFJSUgrA7nvuxVU33ERXV5eduhUR9ub+FObO 77j4HEYfzUAoYj0yLd08af+ullNnyoMIVIR0IWXmZdDZ0cHbby5h8tRpSCTvvPUW4ydOomXrVt5f swYRCOobGhjaOKx3HTevjUcUr7/TlfmUz3LPs2dxLxGp7EDuByyEKANmAwt0vjOBRagFOcai+jbr gdXFume8CHj1SfYDTrBzwpk8UT1mBI/fy/eCegxELJvIVA3P+rIu4zDMu8Vb3MbKt6duxNXslxEv oCWfVWd7F0APW9v1CdIwYJS7p+h6wV1ccJtXKpWKHCvEnVG+PnepVKpb3hQ/Xhk97nIsTXN/20kL i+1EyA+Z92Mup5JIu8vJJlJvt+hI07p1/PC/zmPr1mY2Nm3kku9/j3VrVvP0E49z0X+dy7X/+wua 1q1j44YmQq+zEuc/b5tEdxDycRsrF8L0Kbe7TZrWPZD7AY9ELT1ZDwxHTUsag1p44/fAT3Sa4fSv rovXsdB7DhIFnGCQ4QSB1EIj33iUp6N9iQdSzX2UoYQwBBl6jrzYnfLkG81bFry/ShhiI6rzKI+e xJeUuoy9SdwrODdnMbiTce7yCeycEmwjd56rtTAdriemuPO0Xb/CcwR79Yrw4RcjxqlRZtHOXbRN hmFIe1sbmc4OwjDLxg1NZLJZNjStZ9OGjRx65NFU19TyzltL6ezsKMyrXyIplWdBuvnAfoSz62pF HRKKW7aH195ausVWwgFqal4pajrQcKAEGAEMA+4CNqEs417Pzd0eJPsBJ9gpIUPz6xc2iClviKd/ jRediife7Da+vk0YW9oSfUzfXKfTcdImXcy0lv6xfEWz+cvoVzwlaYtcPC0ibVS3F4e7jdwRSrZs 3syWzZsZOmwYZaWlpEtKBpG7MPpdFJe7gtCKybQdpFQR9+iH6HkOzC6EudHSeJ4Pw4+zZkMZ0tbW FllNDKC2ro6Pn3oaq1e57XTNuXjaKGuR4psLo0dDr8zI6PMqgnochP2AA9Q87jgFG6SU1wkhdh2A MkjYtv2AEwWcYNARon5FejQqZ1qPvxxCVJC78xFdF2vvofDG7DxBrqW5VfY5vxLp0hsjR3jfIydN +py75+iWnDptD4xOj1SLGHf+lno9cNfW0sLjDz1Ia0szM2bNZvykSWocctC4M9rNlbFY3PUGhXn1 0kgivLqtCF0mIvrwSaVT1NXV87dH/0pdfYM6rF3/VdVV1pr272k/52njNvLZltqLiZASs6qYKVKo x4ZNXzdS2b7DXmnmAYdhuGnBggUXEXlyRe85ZYAm4DTUWK9BFrV4SH/DNm1w84BRq3I9UCBtBIkC TjDoENIEgsSErTqbY/HkXfhfuDO5yoDIUfNVyDD6PZ4mJwst3nI2C4hbfbmC00co1dSnoqAgd0LL 4L5xt2HDBu649WYuuPhnLHhpHo0jR1BTU8ebb7yODCXllRVMmjqNbGcHSxcvprOzg4ahQ2loaCBd UsKbixcDMGqX0TQOH55jifWOO5l3nFfq40XjrhtELM6IhlK9uRyHgNfyDKdCxs841NTWcsrZ5/DI A/cDMHP3PSgrr2D0mLHM2mMvQilJl5Qwc/c9KE2XEL9hQQYiZTXlNfUxkdDC/qqcjt7mNhm5aIDn AW8ErgLO0d+fBVpQ2xE+o4914Jan7Fck+wEn2CkRV3vWoSoj35wJZeFH1nqBSPEo5wJRqfmUbFxh xK/PZ6fFXc3qo+/ijX4UbPfC9zl5+twJ+1VvuiCiKU0pXOEVd11hSHt7Gy1bm3n9nwtJp0sIRIqm 9eu4/uqrSJeUUFpaxncu+iEr3n2XG351NdlslsZhwznwsMOorK7hhl/+H9W1tXzkoEM4+ayzyY1C 74G7AtaYsTsFIXm1c5FhOjXGK+Nb8Lm8Cu/dZWDVsdd+zCXl5RV87JRTOf6kkyOrXY0YNYpDjzoa gKHDhnHRZVfY8vjv0ZLmq4A/5uuUsZ1dUKBdbi8Gch6wlLIFuE4I8RsZXe1qOXCnTrMatWdwv2Nb 9gNOFHCCHQAxxRtz/MlospzrnPfPWZ7xRTsiijl2fe7gZFz6y9hx4Qm4ApfFAnai6QXxqULbDsdd gFMYRshKT9hGLbFc7gIhqK6uoXH4cI487gQeuOdPhGEXMgw58LDDGTNuPA/cezfL3n6bB++9h9M/ /RmmzpjJ9Vf9L28vXUpZeTmHHnkUEyZN5p2333JjqBFieuAuh/q42hY5j6t/4Mbs/eERy6vweY1a lQAFp7oR9QKIIIh3SUwO9oj5Fdgn1k0HJMdFLv3gL1dmExUtvb5DMdqkmQcshFjfc+riQPbfUpN9 wrJlyzbV19dfSB+s7UQBJxh0xIWGxNsPWDgnnrVAfMlo0ucEbUliB1SwUl5rWMY+RwNd3FZ05vZh NL0RxNLlEM3d1M9zXRbJivO5s6UyA3uGO6nt4kDaJQ8LcScCKC8vt3UNu7rYsKGJV19+iZeef55V K1eAhDde+yf//o1vkU6n2Xv/j7D8nbfZa++9+d011zDvuWeZtceeZDMZSkpLtTVpytuFz695GoW5 y8NX/xvAkbKZZRul50kw2zn6vMogagGrhNEDMq5AC7aDeFfJfcvpYBJ3iUfnUEfGef0UQg//bF+b jPygBnIe8A4AgVefZB5wgp0SQv/zVw+Sunduj0PsJTGBKlJKOjo72NjUpKKpjVCR7rOU0NHexqrl y92NvUCXrmyW99es0YdUnmFXlvXvr0XG8jFpTKCR+aimfpixNfduy2GtN4m//tF2c2c6K91yJ9Us oDzcqXPeSxdRCEF7ezuvL1zIfgcexImnnc7oMWNZv24tk6ZM5R9/e4IF8+fx0H33UlpWxvJ33+Xs z/0Lp53zKR5+4H47fSbKneieOxl92QRWfEXXjuovmL17bfkxSlm3VYjxGqsXHq9e/X0vTf7pWq5N FkonBBF+XJt1U738e+oiRV45bVLCdvJq+1IDOA94R0G8joXec5Ao4ASDC6ksSivcvOXxkNHAkPhc SpcspGXrVpYufsMzSKWXXtLZ2cEr8+dzwzVX09nRYRW90QL/v70vD7OruPL71X1Lv15et5ZuIbUW BEhGGCIEWAKzTEjmiz2OF7x8trGdmYyXycSxM19mWJJxJiEZbE9m8eAwYycGY4IH22DjIYNh8GSM DR5gEAgQi9FCy5IataRWa2n16+0t91b+uHWqTtW99/XrRd39+O7R13rvbrX8Xt3zq3PqVNXoyAge vP976jhUYqWREfz1fd8zuatFEAS5IW1dGSphNhZtl9YU2H1utthpC5dMnQTsYoriAAlkczlsPH8T vGwGq1avRrGziI2bNuH/PfIwHn3ob1BoLWDf66/j+t/41/jxjx7CQw98HwP9B3HOeRuwbPly3HvX nXj6iSew7e1Xoa29PYKdRbxWVczIuATMgiHCLuOcYVdPOK7CxjU5gM5pE7oDyK5Ti4xZmztCtOo8 9TuSFtyQMG2S//yx5bPeCZ4PpT9jjmzU0n0zkzCAdB5wKk0oEq57FoCgQBepSc249fQXfX9LSwFn 9fZifHIcAwf7UatV4Qc+Nm56K/L5PEojI/je//kWfN9H357duOCii1Ct1XB44HC4CEKlghee3Y5a tYbDAwM4dfI4aurc5MQYjhw6jLGxUWzcdAHyebP6EyuF2YGG/g9ClUeWKFkuc6mHtDVjgZmEnWRZ C11mQ3QSS5Ysxe/c/B8hAVx17T8HAJy1qheXbt0GITwIIVCplNG3dw/edd0HUCgU8NQTP8P6DRvQ 3bMCl2y9HL5fQz6X08SSVG7uSjXYqfvnAbtEETG4mkuqnM4X8jjQSd44ZOA8x+4U9pVIltZQMh+l pbfGLob7ikTG0CMZzG1vZgHmAS8GkUA6DziVZhWuNdSAm44NkeFusCbqlKkhpUyCIByn3P3qL3DO eZO47cu3Yu36c3Dq5Alc9+GP4oqrr8Gp48cxWirhE5/8NH74ve/iC7d+CSeGjuPeu+7AyePHsby7 B21tbTgxNGSdK7S2YuCNQ/jaV/4UHcUifvf3/zPy+WUqe8eq5N8s8y7QH7qzsQDYWUE2VHY9Thy9 xE/ybQ0zmSw6Ojrxox/+T7S0tGDblVehu7sHkGEgl5fN6TQkoxyr2Npd7uQU4YcziF2SSOh1tamA hifttudGOLsLZsAlQOdIz31XHSD9szhMHxkjp6EMR8VbC2tIU9wo8bIFThLBb1j0g/M8D3ihheok gHQecCpNK8pS4xZOgFDrCGG7V+3HQssokBgtlTDwRj9WrV6NTDaLm/7rf8O+1/filptuwOZLL8P2 p5/CBRddhHxLC17d+SJKIyPo27sbra2t+NJtt+PZp5/CnX/xVfTt3YPW1jZ88bbb8dzTT+FbX/9L TIyNYfDIYXz5qz9EPp/XLkhm76jysGOplLAaU2X9B/epBcHO6GURli0yziisUnL69DwPa85ehz// xp2aWBMMN3PdISLyeEhjqpnr84Zdskj9H9gYKSPGGGIL+z9UQpuA6ZDwsPfjlXDjeOM40bL/OSHT GDnPn8KbA52DyV/azYXSmSGq1mPpfsDpPOBUmkwcXWArlyCIKC9bKYWKJpsNNw9oKRSwZetWiIyH js4uAEDp9Gn8zQ/ux7r15+CJx/4eK3t78dw/Po2xsRK2XXU1srkc1q0/B9VqFceHBrHtqquQzWWx bv16SITzOHP5vI7oRYKSNfo6tDxpeU1SkpKR0SwXvregmgl2luuTlc2FWDgmmbvUpGX182PXYovc Zw8rLAR2DQsjYnfGizDh5Mzlj0iHx2PECyjXvxCRZVPN0EC0CHxKmWQ/n/XJuyosDUO89uIzOv05 wnWx7Qc8n5LOA06l6SQkCgkpaDxQst65sa4E1yeCevMqDRWck8lkUKmU8cKz27Ht7Vfh2OBRnH3O OTg+dAxr1p2NP7r9a/B9H6+++ALu/t9fxyc+9Rn85NG/RUdHB37Z9zra2trRs3IVfvLIw+pcX7jb j5Twa37UAheKvGJc0bYbl+phK8U5EQc76P/jsOOWkipdxMUK54siDulirgsAKwFpnpP2jbYIRSkL iV0dIaKKegKcjow2jaHH3Z0HVHo6ZXNBSgTO72Hyp99FBaZp4ncSjHNR0PNsjJ1czUkdormShZgH vFgknQecSpOKshwCaRFvtHfPlI4OlAnvL7SGy/hJtZnAA9+9F1JK/Nv/8Hs41N+Pf/WZf6PGJ7NY d+65WLFyFTZsOh8/+usH8OD996FaqWDrlVdi41vOx48e+IE6V8WlW7eho1jE2664grEPjUuKuMJY n1ICQi9dSJ2LOQwk0vrYKOxY7IiFqbiOD9Kv1TB49Ahqfg2Vchlr163H63t2A0JgZW8vurt7MDE+ jl/u69PrFa9avRp+zQ/vk8DK3tXoXNKF/X192LjpAtSqFfTv348N52+aMXam93AGsGtA7CUpnYsC Dq5S1Sv6O7gWqz4OJCBEZKzWXA6JNMb5A+tGStfq0NDUKKtGsfWbxSIc1oPpPODpzQNOCTiVBRfS v5btpAKIbNeoPRhIgSuZjIdVvb1YcdYKHNx/AO/70EfwgY9eDyC0ANauX8/SAJYv78YffOmPICFx 61duQ61aQy6X0+X54le+imq1ilwuqw2Nz91wsw4ccgNxbMsz/CYlmFHIAocEoLflm6VY1iJBwywz O8947EhKoyX81V13oqOjiMnJSWy78ko89MAPkMlkcOHmi/HBj30MT//85/jJ3z6C9o4OVKtVfP6m m7H3tV146IHv6/ve+Z734jt33Yn3f+R6lEZGsGP7M/i9L/wBw2v62DFDOMQumD129cRqjw6uAfkX qP9g4coGi1VnQf8KmljJIuUWNmv8mqATLF0E9qFVaJ6AezmeeNVofJjP7BaU0neerscAABxcSURB VKPju3btGoGZ4spHzefRhzGv4kYGxH3G1j0l4FQWWMh8MIecOGw7jWlFGMPAqBIPHR0dWNm7Sp+V ljZ3lJciUiJfyUghm82wCFGVkdZPnC7sY16RAE7sr7b05koPSehwHtvAVcq/cezKExP4xUs78dnf vQHnbtiIGz/72/h3N9wIz/Pw7TvvwGWXX457vvG/8Bd334NKpYxbbrwRx44cxR2334bP3XATBAS+ /c078M73vBcfvP7juOXmG9Hd04M/vv1rYS6zwk4y7Oak7zKFqO4LbUMIWmwS8Ra4S34AAiEhAnVO q+EYPczaZGSXJ2m3yTCJ+DFmJ3uGrUi6xdwj3SvTlkYt3TczCQMI5wFLKb0TJ040NAaeEnAqCy56 jiNZuRIqOlbNl3S9aFyYy1p4Aj1nrcSKs1ZGLWrwNBylRHNc6JKjUKP6iZEI6WmEyjJ8XKnSgCly XVFaVakeIo1LBDtm65Dl1gh2EkAul8fGt2xCtVbFqZMn8Njf/RjZTBbFzk4I4aGlpYCurqUYPnUK 527YiFqthlMnTuCxRx9FJhvel8lksHT5cmQyGaxYuRIdXV1OXaeLnbnZsujPsIQdFB6rbOMqLZAR 5TrJfgtqAtK1Q+02acPktEm3FE5HNdpIqaPlEj6f960qIlWXYw7aZDoPOJ0HnEqzieM1ExGlazSQ gFHaEaKUarw1QrCufRH/PnBjN1kXGU0rWb4AG65kY74AVESvY57MpRGM2WMHGQaxhdvg5bHpwovw rvdeB+EJ7H1tF9rb29Hd04OXX3geo6USXnzuWVz34Y+E973vOsDzsPe1cMvCF597Fue/9a0AgBe2 P4MrrvkVlldYHhpcaAw7p77zYUMRMVHAn4srG+MV+pC3HLYICgApbfs2yq112iRsvuT9El4G6eYv qRzx9dMLnAAUEzdT0U+m84DTecCpNJloqpAO9UkAnoiYi5w7eGxo6J7jSk9dE5SLcFKIP2Y2mpWO kzu0knNHfFjIqT2eaeo7V8tJJGKnvQmNYZdvyePCi7cg35JDW3sHPv6pz+C7d9+FJUuXYsXKlVix qhfv+dCH8VffvAOt7W0QQuCsVavwiU9/Bt/51l1YsnQZVqw8CxLAqzt34pb/8Sc4NngU99zxDVx+ 9TVwdY9wLbE62PEOw1xiV09ogQzNTpaFy3ENL8jok4yUzXkj8W0ttk3GVDeyHKYuUjLhGrNZAIJ1 gCSxw4xwtR5K5wGn84BTaVIx7jVjYQoJsyoRqJdvhLtZabTOnVPD52ba+8Hb1o0ORomIu1Oqa5XF dG6lORNJUiblM3NxsaOzjWLXuWQJPn/jzfreiy+9FJsvCTeGz2QymBgbw+lTJ/HR3/hNTExM4JHJ B9DeUcTFl16GzZdcCj8IkFH72v7+rV8EAKxeuw5fuPXLix67emKWw7TPCkbGhnJVewpvsQnN4VXz vNvJi2mTiK8yp+wIgepei7nKcqMZdFY95wLXdB5wOg84lWYTp/MfWbWH30MkC9LFwgpMoXvZcLKJ miVdxNyHErbyc+0PnVGkoErlSRGxcN0EIpaFEPHBPDORJOx0JwYJ2Dmmp1SWJblKlQnnQUAGEl42 i2XdPbjv23ejo6OIX/+t34bwPAWtsDaVbwQ7PSzgYhfhYsf6nEvs6okEW6WLOoPxDmOzhQS3ahWO kTZJY7OBdR/HgdqkdR5RXCNt1f6x1Tk38JCnZzut5wLXdB5wOg84lSYTPSWDVApTUuFyirAsOzsA xlVNFPwS47rTytAxQ5jiYjYMS5eTlYS1jq5lrlmZwVhHlD1T6HM0lSYRO8sai8OOiM3FLl6P53M5 bLvySmy78krbw8B6HcnYcUssZi/lCG7hc3yRizOBXT0JcVU7UTNecjs4gAQ8zXNmepcIO2duZ4/P 6SWCVpft1hYDjXYZ67YFBreJhnd/vHjrmTpipoXOEFeLtdN5wOk84FSaTNw5j8a7J8xpoeNj4608 k5pJQ2kyqTSVPfdV2JYxjHITLik58yPjrAleLn1SkZwbDhXuGTxHBDwL7KIlIAtZ1McuwhZhPn6t iqFjg1i1erW5qCy96LrZPCkHt7CAZxy7eiJFuMikZLjGEjGEClgOa2Lm+dKNdF6lohOKBnNZKSet LCaC8HnHda/bLpzHgHi8FLZCCAgpESTd17joXmo6Dzj2M7bu6X7AqSy8qI3EaU/YQIbcSJuZ69vU P7MpOrlNEfkziwvQOXMcfpXmnMpQ76lq9jWH5BYKGXwsj3rKjcqsT6vI0zkdx0zCTs4MOzkL7EZL I7jvnnsi2GEa2PHzZxy7eiIDBJIQszGti6tVTwkhJVssi8rPFmLRx+pPAxR/HD5qyDdyWxI8Nl+b 5+cG10Yt3TeT9Rsr6X7AqTSfcKsHthOTyMJaZQgSJjzWPOCOHdujbFH9kqRukizsyMQe0qHCKDMr v4CsP/v5OZUE7Iw7WSprV8K6YQrsKrUqDh08iMD30bV0KVoKBRzo60M2l8P6c89DNpdD/4H9gJQo l8tYc/bZmJiYxM4dz8EPfGS8jJUNx06yC9KxdHW15gO7ekKFVMamdgC4S0wq8pXCLp+1SxRrunab TBrHrVempNtk/HlpygiEuFIJAamseo707CSdB5zOA06lmYR65maAi7n6BAxrSu1ujShlPteHnXdV ikUyMceGo+zrkTFjNz1pv2GBslii6aC+gp2u8LQc7ISlrOtgF0kyPF8aHsbX//zP0LtmDS552zac Pj2Mpx7/GVrb2nDtv3gHLtpyCf7yz/4Y68/dgKFjg3jb5Vfg7df8U5VHdAnGRrFzx7TPGHb1xMGV t0faHUpb6ULY7SzShmF1gOx7p1+l6GQmp5VHpie5nVGejoxdoWwGoh9O5wFPbx5w6oJOZcFFwrj2 wu/kViMHn3LzKZde4LjNyFjhLkIKLpFgbjaeH2k/aY7d57WoyFt+LXDylyz/8EAp3UDaLm2e/5xh Bxs7XidFvknYaQyculeqVRw9PICPf/LT2LjpAnz/3m/jk5/9HN79gQ/iO3ffhWqlgtOnhvFb//53 8PmbbsbDD/4Q1WolLNMU2Lm/nY2dmDfsGsJVtROpCsoxJVzj2pyLq1Vf8DZp62VTP17baJukiJ6w LQbRNk9/ahiHfn+dfiC1q1zaRZg+VExoHnAul3t/QqpvNhLWQvOAgyAoNvpMagGnsrhE2l8F85jZ 00K4azmAFJ62+sjYCqQMp9Ho3j/dn2RF2OeltM/yABfLrUdBWpblxI/tFOZ0T1s3T8rG6psH5rZA EbIqSyB9IAY7KYFMJovlPT144+ABTIyP4+8efgie56F39RoAQC6fR2tbG8ZGR9Ha1oZKpawzpk0U tEUOk+6iwa6eMLtN52aF0vDpPcZTI1SglbY4Jdh2keZ56bYqd7tBbtjyzmOk6s7wiqAy8xdHmhEc 3SboIdUOIHkrmbGk84DTecCpNJm4W+nZ7jpGoM4iE5Z7EvFKKoBRfu6etvp+GhdzI0+j6zaa7Hj+ KjCVhtNse4bru7knDrKiotixY+k6KqfGLpynGh60trVhzbqzce073onyxAT69uwGIFEqjWDXKy/j +NAQ8vkWFFpbtXUn3ARZzvxzIbGrJ1PiSk1EXaUejC61VVxhyu+45KlNuq7IyEpXznM2Hq5PgAHJ +5aS2gMvudQjOHMxCpzOA07nAafSZBJRru7cSfU98hzdHiZiLwLFbojoImd3JNcyNko/YfoRn3JJ xWXWhP2QZOOfZ4aAhWAKXnUa6uHGT2vic4KIcrksNr31QgBAR0cRv/prv4bvfPNOtLW3453vuw5C CFQrVTx4/30olydx3Yc/glw+Hz4jRDx2zAJbDNg1ItpN7OJq32XVS7D6SL3kVPxYLZ0NdJv01XkW xAXOo8w0tz4pIdvITd66UbL68RymLdaD6TzgdB5wKs0ukqwJ8z8AFrFLBoewr+lefnjsWmHWJug8 O3Oj+Z/dEiErx4qgq9JRaiLWWsGZdaNq7GwLySzQ4WDHTU9WrWXLu3HzLf8dANDa2or3fPBDeNd1 74dAuOrV0LFBnLdxI/7TH34Rvu8jkwltOHomtvMTa4GF3xcFdvVEdQZ0x0LYv70hYafDoDsdtgU7 ozYJ2OuY8PupJK7hbD/NqmOfC4IAQZCQeGNCJU7nAcd/xtY9JeBUFlR0gBV30ykRlpJj59nT+n/J x3JhNXdtEfDkLdecNFaZVG+LiHkm9mFKQkbK6zoJ55o4dMhNjGVWHzujD4wrdWrsMiKjz7e0FHDh 5ouBQCLjeTqQZ9rYOYQbU4RGsZtDcCVoZanGEmU2p7J2o5ar8dRYj02jTSaEKliP0g3uLZaHxLlz Dtplo5bum5mEAaT7AafSjEKWkeBEYCyKqRSEHuPV9pROge5IsARs0rHcfBJwZ2lqp19CeSLWWkAr JDjkHleUGYqcEXYMmRliV+zqwsd+81M2QaA+dvV+x0awiyl+UuVmha4EGaQ2rlYnS7qo8G8s7kCd ExoTwtmMwdpSv00mP0fFsjs08bhCb0oiIY3VPAdtMp0HnM4DTmXxCVeK0vlzmqfROqGCcNY6jks8 aQxZXyelwzxCbp5QypIpWaPMnLxid1+g++OrRJ/SPVdfpr6ribCzTswAu8i52ckM2iQfa3dwTaiX HTxlrrkdnrq4wiHiBkSv4MYImXubAkmdNFbkmeOqn0znAaf7AafSZOIHPjzPM4sy8IXumclox8VG hfYDntpCncJKcL5ZXkMW4Utzb4FQGZvzTmLOeB7VpkFxX1zrpZdkazY5dvrJKbCTmBZ2sxBTHrOx h9QjmyIQkGyOHK+XLfE4GfzoTOCc58QdU7oGvTCmXIGuAu+osZOwwY/plMSTiHWc7gec7gecyuIV 6+ULgiDwfX+0dHq4o2vpsojyBlRQCW0cINUJbnhwl5y6Holqjlh1UeuAH7tWjFDWSyBV2tJZDkIq inP9t5oZ48fdhBDIZDLC9/1GlZ1OPZvNZgBI3/dFNpOZGju6Vge7iKWPucFO17cOdhCwA4ySsAsk fL8mcSbnmUqJSqWCfD6v+gBs1i6vpuo3GBSpmyMYPlNm5mTt/OQRV3e0rJQRt3BNiZi4GybxzlH0 7hlJOg84nQecyuIXCUCWy+XJ0umRVw/t37+1a8nSTKy2staABgBhKWqpCFkHuEh1jjvtpL3sgVDf yJoiy8w9Hx6RMqVF9R2itbMyhAKwHYccC0MKBEENnucFuVwu5/t+o7hpqVQq5UDKibGRkbbOpUtg MasBh+WtrvP1GWBjF1kcYr6xs4iOYSdNx0EGAUaGhyU8r6Rqk9RRaVSsDk+1Wq1VKpWTx44MLF19 9noRwZVXQMYQnaqn3TGxcRVC6IjjSLDcFJZvgMCZD69KoDtArEPDa6fKKViZbQiECvR246inJw3M A56yS9Ksks4DTmUxS8S6m5ycnBg8NvjqkUNvbD530/lthdZ2AI5VxciUjKI4Qo5ojcji+FDKCUax i0bOM2VGn4GbKNcprmIDs2LCz1q1hqNvHPKr1drJIAiq7IGkeSAcuwAICXi8VNp7+FD/5vbODs/z wlc5ETvOEAB0qDLHTkK5WOcYO060dbHjFTbYSfUJCVQqZRw59EZtfHR0v5PiTIjYbZPBxMTE6LGh oZ8O9Pe/f+WatVlPbSphpnExtzOf3+v0XWQgYxb6VSjpOcC2y99yyUdc9OEdguEa4dgAUZydvKNt UuUcBBgfG5NCiEomk5GOV6aeWD9gzDxguu7BdJiEEELIBZlPNnsRNF5j5vt6AMTg4GBZzQPOwK67 +6klJeBU5lMkwpewBiAYHx8f/+W+fTt7e3uvef0Xr73lvAsuQFtbu7B1mTDKQpiN9MIr3J/GdKCE IRh1QZoEHasgRuII3bEkwnxca0JyYy1c8MOxLAO/hmNHBoKnH//p5MDAoX+oVCoVAD6MckoqFmEH ALVSqVTatWvXT/KtreuKxSXLzlqzChkv69paDDviQmmuMwtZPxcInsCcYBeuRWxjNRV2Jg9TgEq1 jIGDB/wXtz9zbNeuXY8hxI1waZQwXKHnAwByYmJifPDIkV39+/r+2foNG5ctX9EjPC+jU+VR0NQe TT0Es04lEMSwpGVA2xV2Oy6xHRkXf9boJWDl7/yyusz8ahiQBYyOjuD1116tjo2P7/Z9v8owabSD o0lGzQPmJETz13QXD4AU8XPl4vJI6uEuxHUSD4aARVdXV+706dMy4d5ESQk4lfkUTiI+gGB4ePjY 8zt2PCiD4NcnJ8vd6zecm81m84HwPN2QzXKAqnXziFO6jQyO0CBWb3m89qMIVC/hXTHXdQkAqWwf YYxEivw1yRDhmty09SYkapUaxkdL4oVn/nFkZGTk0EsvvbQDrEMCm0RcRUDXfQCB7/vlAwcO7CsW iz+vVSq/cvWvvmNJe7E9yOVaTImENTFpcWHHoonjsNMSBg/Jarkihk8M4cmfPnZ4cHDwycOHDw8o 3Gp1MGtE6LkAQK1Wq9X6+/v3LOvufvKZJ3527aVXXNVZ7OxCNpsRtLEEEH7oXY5CYOGZ/o6uV3Sd 8cgvMo2CsiU+Y9OVdv5SPSEBAWkZyGEMgkTND1CZnJD9+/fXXtrx3IHnd+x4GKad6faGZGwTCau9 vT2/devWjZ7ntQVBcOzkyZOHX375Zb5Ih7z66quLxWKxvVarBdVqdeTxxx+f4Alde+21xdbW1o5F dH0SplMhLrvssp5isbgum82umJycHHjyySf7EjCKbZ8pAadyxkVKKdXYErc2qgAqvu+XDx061Fet Vu8tjY6++5Xnn+3sWt6dLRRaMpCxS7o1jfARTSllMDI8XCudHq4eP358zyuvvPI4FAYI8SBF5yo7 /vL66q8GoFoul0d37tz55Ojo6GSpVLqitb09s3x5Tw4ePMGHZptQtONZeDKo1fyTQ8dqY6OjE/39 /U/s27fvRYS4EWbTJmKnTdZgsC2PjY2Nvvj8838f1GotQ0eP/pPV69YVlnR3t2aE50mpTEwxNxvJ uQTt0jSsq/y5+PNRof6u8gBbD3hyfLxUPTF4fPzI4TeGdu/e/ejw8PAwwjFMHkg1FabudQkAa9eu 7SoWi/8lm81u833/yUKhcP/LL7/8oEpXbNmypX3ZsmXXCyE25vP5chAE2wE8Qols2bKlvbOz82OL 5brv+8+q6wIANm/eXFy1atWnstnshwCsLhQKdwP4kotDPQxTAk5lvoSTTJV9TgIYGxwcPHjixInv d3d3r+/u7j7H87yClDIL5uZZqILPUog4a+Pj4yeHhob2j4yMHAUwilDRVRDiwN1+in2kVNY/nSeS IOIu12q10d27d784MDBwuLu7e11nZ+caKaUnpeQusmYUCSAQQvhCiOqpU6cOnjhx4tDY2NgxhG2m AoOfz56ZjhXM3ddVhMRQBjAxPj5+avv27Q/39PTs6uvrW7tk2bJVmUymIKX0ZAKuxqFvnzsT0ihR Jz0uQnO5NjY6Pnz69KnBI0eO7K1UKicQYssJmDonEmGTjIwwsGypjQoAQbVanQiC4Bnf95d6nrcx n8//SwD/FyHv+IVCYUkmk/k0gF4pZdXzvLUAfkwJL7brmUxmLYBH1WWvUCi0ZzKZdwPIBEHwD5OT k08jOiTCIywj7TMl4FTmS9yXtAwgj/CFnwQwUavVRo4ePdp39OjRIwAKAHLqnmYlYG5hUWdjAsCY +pyAIRHeMXHHg13PARHFOEJ8MqVSSZRKpTEAB9Q56rw0657fHLcyQqxGEcWu5vxNh4S5kpQIf4ea SnssCILs4ODgvsHBwSEArQBa1F8GzYutdrfDYDuOENtRGFwnYTp8nFTctOjT/S737ds3um/fvq9e fvnl9y9dunTz5OTkIZhgrMzhw4dPL1++/MtCiPMBlKvV6nNgmC6265VKZQdY52tgYGCkWCx+IZvN 5vfs2fP8gQMHePSzO5wU2yZFkwaipdJkIoTwEJJCXv21AiiqvyUAOgB0AWgH0AZDwDk0t7Ijq58s tnH1N6L+hgGchiEWsu6qUspA4ZaB6Yy0IsSqAyFuXQgx7IDBrQUh1lk0b8eFOhyEWxmGJE7D4FdC iB3hVpFSNjSvi7XJHELMCNsiQlw71V+bulaA6vDABBY1Q+cwzhVqWfwIcRxHiC398c5ODapNUkIs GpgigaljQp0/fauTt0tKiynIqpHrIuaPi+ux0p1q6WwTllrAqcyX8J53Bubl58oMMO5VIhEiYLeR L0ZCljGf9CJSvSZgWxzj6jz90QvL0+REXkNINln1vAdjLRJuZKVxkiBpBtwA2yol3Dh2Y+p7GcZz MN0J1fz3od+I2mSWXa8gxLwFYXukjo2L5WIlYpdUeKeQ6jaOEFMiYj484rbJMFEzREJ5cG8N3w2J kxSRkWDXkyxrIB7ThbjOy8nP8bpR3eMkHQNOZeFEvaz08hH58pdUIupabYGxfptxPJPqRHUmZUcK j1x+ZL0RGcQFtVBaQIjFBAweRByTMJYykQjd3yzChypo/NEl4TH1RyRB7ud60brRjEybJItQR7eq W8hNO4GwLeZhOoRJcz0Xm8SRG+90kIdhEsbiHYfdJpNc0G66U5EwYN5jnhZvn4vBwm3kOq8Pv+YO Gel3OW7ec0rAqcy30MtPJMLJhdxhpOjIjRr3Ii924STqEgkfDyYCJgssABDQy8qidXmAS4Xlwy20 AozXgNyBSW6yxSiRcUQYVylhRkFChB+30iIuvgbzrCHEh8Z/uRKlfDn55tA8mLrCPSrUJundI1zp O10n92mEQBwrmCxbnx1nYLttqQzNLlQHHXQGm3h5Rzqx85IScCrzKZxISCbVJ02vIVcfjSVxS6PZ FB4P8CFlzomYrA+yjpOCNbjSBNg8Stiu0wnYnZZmjCDnFjDVjyxcHf3NvsctGtF4ZqaDQ9gKhG2Q e2rIo0AdG3I/NxOuXDi21H74mDCRMrXJutavE60PhBgRMRH51vPC1LNAG52RtVDXuSSRb6z1C6QE nMo8CntROQHTd1KwWZgxzmYlES68Z0xkwpUeETIf57VeVkYSYPfz4I4qDDnwqVvNThKAIQmXiH32 SdbvTC0rTsCA3SbzCEmJxyK47udmEu5doDbE2yW1rSq7Z0psY0iYcCJvV9LzjVrGcWPFC3U96T7X 7Wy5oGMTTaOgU5lvYdGTFChE38ni5WNsSQS8mJVfXDAWJ1c+LkxTZ3ikZOxLqaJ2OXY84pR3WOp1 XJoNN25VuGRhWRqzWVvYWd+X2h5vj55zrdnF7eC4kbucfBv2LKg2CkQ7gUmY1QvGcu9byOtc6nmp 3HFg1MMvJeBUFkQSpjCAfeeR0c1qbQDsRWTfeVSp1WueikRicHOtMnd6TDPi5hIxd+NHrIwZjPvG CsMWiI6hu+PpzRTYxiVunJ0PC/Fhk2l7FRwMPed75PbppL1IZCoXNH1qnOthmBJwKgsqMYQC9hkX YdosLy1/seKmFVl/01F0jpJzCYKLi2MzSJybLxYzzM7tXFcSiMTFvNnExcolY91RnCNvAtB4R3A6 FuhiFd42gUY61CkBp7IYhO2MEke2zajsuMSSylyQRwxuzdhZqSfuGNoZI9164uzc82bAFWC4zjWm U7zPbxZJwkwCjWGaEnAqTSUJW5gtOllse52muKWy0DJFG6xnAU8VpHWmr08pM223KQGnkkoqqaSS ygJIswYSpJJKKqmkkkpTy/8HJyi5YROM5i0AAAAASUVORK5CYII= --_004_0AE6CEDC831740748F58CAB5409F167Axconnectnet_-- From sumanth@cablelabs.com Wed Apr 4 08:09:02 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742A321F8826 for ; Wed, 4 Apr 2012 08:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.137 X-Spam-Level: ** X-Spam-Status: No, score=2.137 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FZnzT5vCKJJ for ; Wed, 4 Apr 2012 08:09:02 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E47FC21F8824 for ; Wed, 4 Apr 2012 08:09:01 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q34F91h0018610 for ; Wed, 4 Apr 2012 09:09:01 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 04 Apr 2012 09:09:01 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 Apr 2012 09:09:01 -0600 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Wed, 4 Apr 2012 09:09:00 -0600 Thread-Topic: DRAFT minutes of the DRINKS design team call on 2012-04-04 Thread-Index: Ac0SdNEq+/un0d7uQCahlRwpY3oTgg== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F2BCBAD9B@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] DRAFT minutes of the DRINKS design team call on 2012-04-04 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:09:02 -0000 IETF DRINKS DESIGN TEAM CALL=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 4/4/2012, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Dean Willis - Vikas Bhatia - Manjul Maharishi - David Schwartz - Jeremy Barkan - Sumanth Channabasappa=20 Apologies: - Syed Ali - Ken Cartwright - Alexander Mayrhofer ACTION ITEMS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Design Team] Resolve open issues raised at IETF83 (see proposals from Davi= d, Jeremy) and previous issues (Internationalization by Alex) [WG Chairs] Resolve authorship across I-Ds, and seek early reviews [Dean] Send the proposal around the use of RFC4501, and corrections to SPPF= that were discussed at the IETF=20 (Also see AIs from the IETF WG meeting last week) AGENDA =3D=3D=3D=3D=3D=3D 0/ IETF83 recap 1/ Follow-up on open issues discussion from IETF83 2/ Next Steps NOTES =3D=3D=3D=3D=3D 0/ IETF83 recap - Notes have been posted at: http://tools.ietf.org/wg/drinks/minutes =20 - [Sumanth] Proposed that we continue to discuss the open issues raised = at the meeting, so that we can quickly resolve and complete the work 1/ Follow-up open issues discussion from IETF83 - David re-iterated his proposal around; see: http://www.ietf.org/mail-a= rchive/web/drinks/current/msg01152.html - Here's a summary of the issues from the mailing list: * comments about the name "route" (e.g. RteGrp and RteRec) not being a= ccurate as LUF involves finding a target and not a location and as such the= current model is inaccurate * proposal to use the more standard term "SED" and rename RteGrp -> Se= dGrp, RteGrpOffer -? SedGrpOffer, etc. * Comments about a missing abstraction layer clearly disambiguating th= e LUF and LRF resolution types - We had various discussions regarding this proposal; while there was ge= neral consensus around clarifying the intent and the usage, not everyone (M= anjul, Vikas, Sumanth) thought that the current proposal provided that addi= tional clarity. However, as at the IETF, there was general agreement to ren= ame route record, perhaps to SED record?=20 - After some discussion, Dean proposed that we may want to consider RFC4= 501 ( Domain Name System Uniform Resource Identifiers) and use URIs for all= the different "SED records" (NAPTR, NS record, target URI...) > This seemed more acceptable since it is not a radical change and may= provide the additional clarity. However, we need to take a look at RFC4501= and see if this will meet our needs - In summary, there was general consensus around: > Rename 'Route Record' to 'SED Record' > Use RFC4501 to represent the various SED record types=20 - The plan is to look at this offline and discuss on the mailing list to = ascertain feasibility 2/ Next Steps - Continue discussions on the mailing list to resolve open issues - Plan for incorporation of the proposals for a quick turnaround and WGL= C From dean.willis@softarmor.com Wed Apr 4 18:05:51 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8311E8074 for ; Wed, 4 Apr 2012 18:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj8ujT0yUXIB for ; Wed, 4 Apr 2012 18:05:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5973721F855B for ; Wed, 4 Apr 2012 18:05:50 -0700 (PDT) Received: by iazz13 with SMTP id z13so1253463iaz.31 for ; Wed, 04 Apr 2012 18:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=TMTGg0gCAaqm/Axkl+yV6ICQJNpEtSHyeKjBWGjva8k=; b=BcEG5ynTQhPGDe/02eUR7nIf4zG7uu+cfLOxGHns3+Bh+rT5dNdDo+KQrhC99Jj370 o/qvYK4Mu5yFtNfQ6E/kfmgcTX9iC1wpgR91rjzAGZtDyRbTSKd5cfhkV0YzYDictvSi gvBP8vy0eAfkLsoCn5zdU5eT9fveiVNvdediM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=TMTGg0gCAaqm/Axkl+yV6ICQJNpEtSHyeKjBWGjva8k=; b=PzxaXu1D7l/HhXCQndKWdy+vpYnYnxXDxqAwoBsqYWIxxHPmnQR4reK7z6Nms61shT 86haTSnHwgVemc++UgzMXhVNtAe/Kx8kV8b4p+AndT+HeW/0rAwRCUVskOAoUs5mlkPZ 97yNLdo+bbPeBG1WOb0QC/VrdLziZEsDPdaQe8CadV8P+KleISfCqZHJjp8MJBxyvROO ey+StcvekbMgJp95HZ1XsVY1GS8W6f23iHC/6ZTC8zuRVSkpZiBBsnh4khN8sB0NoGDQ d7Vz9OV/3AKGb7qn3NgU7H1hSl6xsieOp0Je7mbS79jH4NRRH65eLv6vMkj5f7MXRuHJ g2QQ== Received: by 10.60.170.172 with SMTP id an12mr729742oec.44.1333587949852; Wed, 04 Apr 2012 18:05:49 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id xh3sm2485329obb.13.2012.04.04.18.05.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 18:05:49 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <243F061D-CAD2-49DA-93A4-A44943AF6707@softarmor.com> Date: Wed, 4 Apr 2012 20:05:48 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmUqh54z2GjwP8jmLgPq6hj/TkUjdexMPX/NUwcG/GxrJFw6rdDF0bOmlGJyJJhVsjnxFbG Subject: [drinks] Following up on SED data types from today's design call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 01:05:51 -0000 David S. sent out an email before the call today that proposed an = abstracted restructuring of the Route Record into a SED Type, with = subtypes Location and Target. Discussion on today's call seemed to reveal that we might be able to = address his concerns with something simpler.=20 I think we've been getting tangled up between the two basic questions = about SED data: 1) What is the data?=20 Is it a SIP URI?=20 An NS record?=20 A NAPTR record?=20 A routing number?=20 A SPID?=20 An XMPP URI? A tel: URI? An H.323 URI? An arbitrary string? A template to which we apply a regex transform using the 2) What are we supposed to DO with the data once, we have it in hand? Route the request there? Retarget the call to that destination? Use the service indicated by the SED data to look up a next = action? Use the SED data as a key into some other routing database I'd argue that most of the "What is it" problems become moot if we = simple say "It's a URI", because examination of a naked URI tells us a = lot about the encoded data. We know to use a SIP URI with SIP, an XMPP = URI with XMPP, and so on. For NSType and NAPTRType, we have RFC 4501 = "Domain Name System Uniform Resource Identifiers". We probably also need = an optional regular expression for further processing of the SED data. So if we answer #1 by saying "It's a URI, dude! And it might have a = regex with it!" we have answered half the question space. This might not = cover SPIDs (still a standards-undefined-thing) and telephone number = ranges (which are partially specified in RFC 3966). But it does cover = the cases in draft-ietf-drinks-spp-framework-01. As for question #2: David seems to think that there are are a couple of roles for SED data, = mostly using RFC 5486 terms, and that we need to tell the recipient of = the SED data how to use that data; that is, what the role of the data = is. So far, this makes sense to me. The next step is where it gets = fuzzy.... We seem to have: LUF, which we query for a new target domain to which we should route the = request. I THINK David called this a TargetType in his morning email. LRF, which we query for a signaling-function to which we will send the = actual request. I THINK David called this a LocationType in his morning = email. SPID, which we somehow use magically as sort of a LUF for an LRF; in = other words, we use the SPID to find a LUF which will give us an LRF. RN, or routing number, which seems to work like a SPID but is itself a = phone number. I'm not sure this makes sense, either. Then again, the subtlety of LRF = and LUF has always escaped me. A SIP proxy in domain X might route an = INVITE, or it might redirect it, and in either case the "target" might = be in domains X or Y, and if you send it a request, you have to be = prepared for it to do either. I think instead we have two possible "types" of responses. 1) A next-hop URI. If it's the sort of URI that gets queried (NS), the = user queries it. If it's the sort of URI that you send the request to = and it routes or redirects (SIP, XMPP), the user sends the request to = it, and the right thing happens. Given a URI, why does a user need to = know whether it's an LUF or an LRF? 2) A transformation. The user takes the response, applies it to the = existing data using a regex-replacement, and tries again. In the framework, this "transformation" is muddled up in a combination = of the URIRteRecType (framework-01, bottom of page 33) and its = pattern, and the EgrRteType (framework-01, page 38). This confuses me = beyond all comprehension. Could we solve the whole can of worms by replacing "Egress Route" and = "Route Record" with a "SED Record" containing the base type plus a URI = plus a regex? -- Dean From dean.willis@softarmor.com Wed Apr 4 18:57:07 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC13411E80A0 for ; Wed, 4 Apr 2012 18:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.367 X-Spam-Level: X-Spam-Status: No, score=-103.367 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Joe7OukoYVHK for ; Wed, 4 Apr 2012 18:57:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6D11E8073 for ; Wed, 4 Apr 2012 18:57:06 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1280799obb.31 for ; Wed, 04 Apr 2012 18:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to:mime-version:x-mailer; bh=L31HzNYeDj1tyZqDmX6TQn0npTPfCjYF9Pb0D0weLAM=; b=HHqFPVm4KQXZ90rEq3MewrxqZ+U0+L/RqtWcXmjgl/zl4LvTcHYr1EAMhAkAQwpXJ3 xAcaMqIQWOA4FclEh+VUysS5altnTDZEv65HPnog/3Zz5Ia7RPUsLXNOLZbL7qPmdCj0 cURyOWQYE8KhEV+LC5bJcPN+s7N5M4lD/WHDQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to:mime-version:x-mailer :x-gm-message-state; bh=L31HzNYeDj1tyZqDmX6TQn0npTPfCjYF9Pb0D0weLAM=; b=gQGsKns4+gkKPurkGLwZxkU7i3u88tqGIOb1FwvRsG2B/cmY8oNTkzO3NCTFhFFpqc woSN/8DlJEkLau1wQJTJpSvqNJVmkjQAZhRjQp7Ip3GdT0OGggYFOwvBeVfNYO4HXtTP TFDrmKSvERtmp5u3hjg+m/l7KEZzLHtbaqxE0/LqHBnCczFiLpFSfKa/8foY0ihHwKxC mYqPG7NxgBwrb69GAsC0myhKfS9GgyOidXZz21q3mc/5vLOEwRrSwWhbabTaB7yAjCba +qleOKhtEdIWiDuskz5tHvKHRtD3kazHB4p0hqgBKv+5alQbg17W/nMHC4Klnpwf+x9Q GtgQ== Received: by 10.60.9.38 with SMTP id w6mr925127oea.41.1333591026241; Wed, 04 Apr 2012 18:57:06 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id in4sm2640535obb.2.2012.04.04.18.57.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 18:57:05 -0700 (PDT) From: Dean Willis Content-Type: multipart/alternative; boundary=Apple-Mail-1-949022942 Message-Id: Date: Wed, 4 Apr 2012 20:57:04 -0500 To: drinks@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkZLWrNgz3SwiQKJnQKXWcUIpJemMPB+mOHWz+Ux26wgr2io+/prR4oSpcK/Tfo82wVgHyg Subject: [drinks] What do we mean by "peering"? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 01:57:08 -0000 --Apple-Mail-1-949022942 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Peering seems to be a very loaded term. When David explains it to me, it = seems it means to him a whole lot of business-specific rules related to = the routes along which calls can be made. It includes things like = time-of-day, pricing, periodic contractual commitments with different = rates, available bandwidth, available QoS, SLAs and all those myriad = things that make up the black magic of the "policy server". We have a much simpler view of "peering" in the framework document. = Here, we merely concerned with the sharing of routes. We have a route, = we offer it to someone, and if they accept the route, it will appear = when they appropriately query the engine that access our data (although = how said database determines query-identity/authority using the = information in the database seems to be perplexingly out of scope). But in short, what we're really talking about is a sort of per-route = access-control list that has two facets: the "Is allowed to see this = route" facet, and the dependent "wants to see this route in its = responses" facet. As far as I can tell, we don't even have a way to = retract permission once granted; the only option is to to retract a = route accepted by example.com is to delete the route, then re-offer it = to everybody on the old list except example. com, then wait for them to = accept the "new" route. Personally this seems like a clusterpluck, but = it's what we agreed to. While we could certainly quibble forever on cleaning up this semantics = in the protocol (and end up with the "Session Establishment Data Sharing = Protocol), it's been proposed that we don't need to, and that all we = need to do is to explain this concept of "peering by sharing routes" = succinctly within the draft. Let me try by re-writing the introduction: 1. Introduction Service providers and enterprises use registries to make session routing = decisions for Voice over IP, SMS and MMS traffic exchanges. This = document is narrowly focused on the provisioning framework for these = registries. In other words, the goal is to allow users to put session = establishment data (SED) into a registry, to share that SED selectively = with other users of that registry, and to allow those other users to = further select a subset of that SED for use in their own applications. = The requirements and use cases driving this framework have been = documented in [RFC6461 ], and the reader is expected to be familiar with = the terminology defined therein. The SED described in this framework is limited to simple routing data. = Although the terms "peer" and "peering" are used, these refer only to = the sharing of basic call routing information between users of the = registry, and do not address the broad range of policy factors that = might be used in a commercial peering "clearinghouse" operation. In = short "peering organizations" are other users of the same registry, and = "peers" are users of that registry to whom the offer of sharing specific = SED has been extended, and who have accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from = registry, registry to local data repository and registry to registry, as = shown here: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This = document defines an abstract framework for the interaction of registry = clients with registries, referred to as the Session Peering Provisioning = Framework (SPPF). This abstract framework is to be mapped into specific = protocol bindings in other documents, initially to SOAP in = [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by = various downstream SIP signaling systems to route a call to the next hop = associated with the called domain. These systems typically use a local = data store ("Local Data Repository") as their source of session routing = information. More specifically, the SED data is the set of parameters = that the outgoing signaling path border elements (SBEs) need to initiate = the session. See [RFC5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the = registry to be selectively shared with other SSPs. Subsequently, a = registry may distribute the provisioned data into local data = repositories used for look-up queries (identifier -> URI) or for lookup = and location resolution (identifier -> URI -> ingress SBE of terminating = SSP). In some cases, the registry may additionally offer a central = query resolution service (not shown in the above figure). Typically, = this query resolution service will be something like an ENUM [RFC 3761] = server or a SIP [RFC 3261] proxy or redirect server. The roles of "client" and "server" are abstract and only apply to the = requesting and responding roles in given transactions and are not = related in any way to the type of entity participating in a protocol = exchange. For example, a registry might also include a "client" when = such a registry initiates a connection (for example, for data = distribution to an SSP). ... continue with existing text from "A key requirement..."= --Apple-Mail-1-949022942 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


We have a much = simpler view of "peering" in the framework document. Here, we merely = concerned with the sharing of routes. We have a route, we offer it to = someone, and if they accept the route, it will appear when they = appropriately query the engine that access our data (although how said = database determines query-identity/authority using the information in = the database seems to be perplexingly out of = scope).

But in short, what we're really talking = about is a sort of per-route access-control list that has two facets: = the "Is allowed to see this route" facet, and the dependent "wants to = see this route in its responses" facet. As far as I can tell, we don't = even have a way to retract permission once granted; the only option is = to to retract a route accepted by example.com is to delete the route, then = re-offer it to everybody on the old list except example. com, then wait = for them to accept the "new" route. Personally this seems like a = clusterpluck, but it's what we agreed = to.


While we could certainly = quibble forever on cleaning up this semantics in the protocol (and end = up with the "Session Establishment Data Sharing Protocol), it's been = proposed that we don't need to, and that all we need to do is to explain = this concept of "peering by sharing routes" succinctly within the = draft.


Let me try by re-writing = the introduction:


1. =  Introduction

Service providers and enterprises = use registries to make session routing decisions for Voice over IP, = SMS and MMS traffic exchanges. This document is narrowly focused on = the provisioning framework for these registries.  In other = words, the goal is to allow users to put session establishment data = (SED) into a registry, to share that SED selectively with other users of = that registry, and to allow those other users to further select a subset = of that SED for use in their own applications.  The = requirements and use cases driving this framework have been = documented in [RFC6461 ], and the reader is expected to be = familiar with the terminology defined = therein.

The SED described in this framework is = limited to simple routing data. Although the terms "peer" and "peering" = are used, these refer only to the sharing of basic call routing = information between users of the registry, and do not address the broad = range of policy factors that might be used in a commercial peering = "clearinghouse" operation. In short "peering organizations" are other = users of the same registry, and "peers" are users of that registry to = whom the offer of sharing specific SED has been extended, and who have = accepted that offer.

Three types of data flows = are described in [RFC 6471]: client to/from registry, registry to local = data repository and registry to registry, as shown = here:



    *--------*         =       *------------*           =     *------------*
    |   =      | (1). Client   |         =    | (3).Registry  |           =  |
    | Client | <-----------> | =  Registry  |<------------->|  Registry =  |
    |        |   to = Registry |            |  to Registry =  |           =  |
    *--------*         =       *------------*           =     *------------*
        =                     =       /  \             =              \
        =                     =      /    \           =               =  \
                =                 /     =  \                   =        \
        =                     =    /        \         =                 =  v
                =               /       =    \                 =         ...
        =                     =  /           =  \
                =             / (2). Distrib = \
                =            / Registry data =  \
                =           /  to local data   = \
                =          V      store   =       V
                =         +----------+       = +----------+
                =         |Local Data|       |Local = Data|
                =         |Repository|       = |Repository|
                =         +----------+       = +----------+

                =      Three Registry Provisioning = Flows


This document = addresses only the (1) Client to Registry aspect.  This = document defines an abstract framework for the interaction of registry = clients with registries, referred to as the Session Peering = Provisioning Framework (SPPF).  This abstract framework is to be = mapped into specific protocol bindings in other documents, initially to = SOAP in [draft-ietf-drinks-spp-soap].

The data = provisioned for session establishment is typically used by various = downstream SIP signaling systems to route a call to the next hop = associated with the called domain.  These systems typically use = a local data store ("Local Data Repository") as their source of = session routing information.  More specifically, the SED data = is the set of parameters that the outgoing signaling path border = elements (SBEs) need to initiate the session.  See [RFC5486] = for more details.

A "terminating" = SIP Service Provider (SSP) provisions SED into the registry to be = selectively shared with other SSPs. Subsequently, a registry may = distribute the provisioned data into local data repositories used = for look-up queries (identifier -> URI) or for lookup and = location resolution (identifier -> URI -> ingress SBE of = terminating SSP).  In some cases, the registry = may additionally offer a central query resolution service (not = shown in the above figure). Typically, this query resolution = service will be something like an ENUM [RFC 3761] server or a SIP [RFC = 3261] proxy or redirect server.

The roles of =  "client" and "server" are abstract and only apply to the = requesting and responding roles in given transactions and are not = related in any way to the type of entity participating in a protocol = exchange.  For example, a registry might also include a = "client" when such a registry initiates a connection (for example, for = data distribution to an SSP).

... continue with = existing text from "A key requirement..."
= --Apple-Mail-1-949022942-- From dschwartz@xconnect.net Thu Apr 5 01:29:54 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219C921F85D4 for ; Thu, 5 Apr 2012 01:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[AWL=2.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN5yQK+DcB+l for ; Thu, 5 Apr 2012 01:29:53 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1052A21F85D2 for ; Thu, 5 Apr 2012 01:29:51 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 5 Apr 2012 11:29:49 +0300 From: David Schwartz To: Dean Willis Date: Thu, 5 Apr 2012 11:29:47 +0300 Thread-Topic: [drinks] What do we mean by "peering"? Thread-Index: Ac0TBkPFVUvgjCaBSxaCCnEUX4LNxA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FD7BD60F6ED742E78D542952ACFB18EAxconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] What do we mean by "peering"? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:29:54 -0000 --_000_FD7BD60F6ED742E78D542952ACFB18EAxconnectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dean I am ok with your proposal. Here is a slight modification of the second par= agraph... The SED described in this framework is limited to simple routing *** and ta= rgeting *** data. Although the terms "peer" and "peering" are used, these r= efer only to the sharing of basic call routing *** and targeting *** inform= ation between users of the registry, and do not address the broad range of = policy factors that might be used in a commercial peering "clearinghouse" o= peration. In short "peering organizations" are other users of the same regi= stry, and "peers" are users of that registry to whom the offer of sharing s= pecific SED has been extended, and who have accepted that offer. :D On Apr 5, 2012, at 4:57 AM, Dean Willis wrote: Peering seems to be a very loaded term. When David explains it to me, it se= ems it means to him a whole lot of business-specific rules related to the r= outes along which calls can be made. It includes things like time-of-day, p= ricing, periodic contractual commitments with different rates, available ba= ndwidth, available QoS, SLAs and all those myriad things that make up the b= lack magic of the "policy server". We have a much simpler view of "peering" in the framework document. Here, w= e merely concerned with the sharing of routes. We have a route, we offer it= to someone, and if they accept the route, it will appear when they appropr= iately query the engine that access our data (although how said database de= termines query-identity/authority using the information in the database see= ms to be perplexingly out of scope). But in short, what we're really talking about is a sort of per-route access= -control list that has two facets: the "Is allowed to see this route" facet= , and the dependent "wants to see this route in its responses" facet. As fa= r as I can tell, we don't even have a way to retract permission once grante= d; the only option is to to retract a route accepted by example.com is to delete the route, then re-offer it to everybody on the = old list except example. com, then wait for them to accept the "new" route.= Personally this seems like a clusterpluck, but it's what we agreed to. While we could certainly quibble forever on cleaning up this semantics in t= he protocol (and end up with the "Session Establishment Data Sharing Protoc= ol), it's been proposed that we don't need to, and that all we need to do i= s to explain this concept of "peering by sharing routes" succinctly within = the draft. Let me try by re-writing the introduction: 1. Introduction Service providers and enterprises use registries to make session routing de= cisions for Voice over IP, SMS and MMS traffic exchanges. This document is = narrowly focused on the provisioning framework for these registries. In ot= her words, the goal is to allow users to put session establishment data (SE= D) into a registry, to share that SED selectively with other users of that = registry, and to allow those other users to further select a subset of that= SED for use in their own applications. The requirements and use cases dri= ving this framework have been documented in [RFC6461 ], and the reader is e= xpected to be familiar with the terminology defined therein. The SED described in this framework is limited to simple routing data. Alth= ough the terms "peer" and "peering" are used, these refer only to the shari= ng of basic call routing information between users of the registry, and do = not address the broad range of policy factors that might be used in a comme= rcial peering "clearinghouse" operation. In short "peering organizations" a= re other users of the same registry, and "peers" are users of that registry= to whom the offer of sharing specific SED has been extended, and who have = accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from regis= try, registry to local data repository and registry to registry, as shown h= ere: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This docum= ent defines an abstract framework for the interaction of registry clients w= ith registries, referred to as the Session Peering Provisioning Framework (= SPPF). This abstract framework is to be mapped into specific protocol bind= ings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by various= downstream SIP signaling systems to route a call to the next hop associate= d with the called domain. These systems typically use a local data store (= "Local Data Repository") as their source of session routing information. M= ore specifically, the SED data is the set of parameters that the outgoing s= ignaling path border elements (SBEs) need to initiate the session. See [RF= C5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the registry= to be selectively shared with other SSPs. Subsequently, a registry may dis= tribute the provisioned data into local data repositories used for look-up = queries (identifier -> URI) or for lookup and location resolution (identifi= er -> URI -> ingress SBE of terminating SSP). In some cases, the registry = may additionally offer a central query resolution service (not shown in the= above figure). Typically, this query resolution service will be something = like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server= . The roles of "client" and "server" are abstract and only apply to the requ= esting and responding roles in given transactions and are not related in an= y way to the type of entity participating in a protocol exchange. For exam= ple, a registry might also include a "client" when such a registry initiate= s a connection (for example, for data distribution to an SSP). ... continue with existing text from "A key requirement..." --_000_FD7BD60F6ED742E78D542952ACFB18EAxconnectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dean

I am ok with your proposal. Here is a slight modification of the second pa= ragraph...

The SED described in this framework is = limited to simple routing *** and targeting *** data. Although the terms "p= eer" and "peering" are used, these refer only to the sharing of basic call = routing *** and targeting *** information between users of the registry, an= d do not address the broad range of policy factors that might be used in a = commercial peering "clearinghouse" operation. In short "peering organizatio= ns" are other users of the same registry, and "peers" are users of that reg= istry to whom the offer of sharing specific SED has been extended, and who = have accepted that offer.

:D

<= div>
On Apr 5, 2012, at 4:57 AM, Dean Willis wrote:


Peering seems to be a very loaded term. = When David explains it to me, it seems it means to him a whole lot of busin= ess-specific rules related to the routes along which calls can be made. It = includes things like time-of-day, pricing, periodic contractual commitments= with different rates, available bandwidth, available QoS, SLAs and all tho= se myriad things that make up the black magic of the "policy server".
=


We have a much simpler view of "peering"= in the framework document. Here, we merely concerned with the sharing of r= outes. We have a route, we offer it to someone, and if they accept the rout= e, it will appear when they appropriately query the engine that access our = data (although how said database determines query-identity/authority using = the information in the database seems to be perplexingly out of scope).

But in short, what we're really talking about is a so= rt of per-route access-control list that has two facets: the "Is allowed to= see this route" facet, and the dependent "wants to see this route in its r= esponses" facet. As far as I can tell, we don't even have a way to retract = permission once granted; the only option is to to retract a route accepted = by example.com is to delete the route, = then re-offer it to everybody on the old list except example. com, then wai= t for them to accept the "new" route. Personally this seems like a clusterp= luck, but it's what we agreed to.


W= hile we could certainly quibble forever on cleaning up this semantics in th= e protocol (and end up with the "Session Establishment Data Sharing Protoco= l), it's been proposed that we don't need to, and that all we need to do is= to explain this concept of "peering by sharing routes" succinctly within t= he draft.


Let me try by re-writing = the introduction:


1.  Introduc= tion

Service providers and enterprises use registries to= make session routing decisions for Voice over IP, SMS and MMS traffic= exchanges. This document is narrowly focused on the provisioning fram= ework for these registries.  In other words, the goal is to allow= users to put session establishment data (SED) into a registry, to share th= at SED selectively with other users of that registry, and to allow those ot= her users to further select a subset of that SED for use in their own appli= cations.  The requirements and use cases driving this framework h= ave been documented in [RFC6461 ], and the reader is expected to = be familiar with the terminology defined therein.

=
The SED described in this framework is limited to simple routing data.= Although the terms "peer" and "peering" are used, these refer only to the = sharing of basic call routing information between users of the registry, an= d do not address the broad range of policy factors that might be used in a = commercial peering "clearinghouse" operation. In short "peering organizatio= ns" are other users of the same registry, and "peers" are users of that reg= istry to whom the offer of sharing specific SED has been extended, and who = have accepted that offer.

Three types of data flow= s are described in [RFC 6471]: client to/from registry, registry to local d= ata repository and registry to registry, as shown here:

=


<= /font>
  &= nbsp; *--------*               *--------= ----*               *------------*
   = |        | (1). Client   |       &= nbsp;    | (3).Registry  |          = ;  |
    | Client | <-----------> |  Registry  |<= ------------->|  Registry  |
    |       &nbs= p;|   to Registry |            |  t= o Registry  |            |
<= div>    *------= --*               *------------*   =             *------------*
<= font class=3D"Apple-style-span" face=3D"Courier">       = ;                     &nb= sp;     /  \              = ;            \
          &= nbsp;                    =  /    \               &n= bsp;          \
            =                     / &nb= sp;    \                 =          \
             = ;                  /   &n= bsp;    \                =          v
            &nbs= p;                 /     =      \               &nbs= p;         ...
             =                /     &nb= sp;      \
                &= nbsp;           / (2). Distrib \
=       &nbs= p;                    / R= egistry data  \
                 =         /  to local data   \
      &n= bsp;                  V  =    store         V
         = ;               +----------+   &nbs= p;   +----------+
                &nbs= p;       |Local Data|       |Local Data|
   = ;                     |Re= pository|       |Repository|
          &nbs= p;             +----------+     &nb= sp; +----------+

                   =  Three Registry Provisioning Flows

<= div>
This document addresses only the (1) Client to Regi= stry aspect.  This document defines an abstract framework for the inte= raction of registry clients with registries, referred to as the Sessio= n Peering Provisioning Framework (SPPF).  This abstract framework is t= o be mapped into specific protocol bindings in other documents, initially t= o SOAP in [draft-ietf-drinks-spp-soap].

The data p= rovisioned for session establishment is typically used by various down= stream SIP signaling systems to route a call to the next hop associate= d with the called domain.  These systems typically use a local da= ta store ("Local Data Repository") as their source of session routing = information.  More specifically, the SED data is the set of param= eters that the outgoing signaling path border elements (SBEs) need to = initiate the session.  See [RFC5486] for more details.

A "terminating" SIP Service Provider (SSP) provisions = SED into the registry to be selectively shared with other SSPs. S= ubsequently, a registry may distribute the provisioned data into local= data repositories used for look-up queries (identifier -> URI) or = for lookup and location resolution (identifier -> URI -> ingress = ;SBE of terminating SSP).  In some cases, the registry may additi= onally offer a central query resolution service (not shown in the abov= e figure). Typically, this query resolution service will be something like = an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server.
The roles of  "client" and "server" are abstract and = only apply to the requesting and responding roles in given transactions and= are not related in any way to the type of entity participating in a protoc= ol exchange.  For example, a registry might also include a "clien= t" when such a registry initiates a connection (for example, for data distr= ibution to an SSP).

... continue with existing tex= t from "A key requirement..."
<ATT00001..c>
= --_000_FD7BD60F6ED742E78D542952ACFB18EAxconnectnet_-- From dschwartz@xconnect.net Thu Apr 5 02:11:21 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75E21F8454 for ; Thu, 5 Apr 2012 02:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxSx3eAKpX3P for ; Thu, 5 Apr 2012 02:11:20 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id CF68A21F8656 for ; Thu, 5 Apr 2012 02:11:19 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 5 Apr 2012 12:11:18 +0300 From: David Schwartz To: Dean Willis Date: Thu, 5 Apr 2012 12:11:17 +0300 Thread-Topic: [drinks] Following up on SED data types from today's design call Thread-Index: Ac0TDA9ILZcxvAaiRjm5y5oKl0cArA== Message-ID: <48B10C7B-57AD-47AF-93BE-AF667D926E0A@xconnect.net> References: <243F061D-CAD2-49DA-93A4-A44943AF6707@softarmor.com> In-Reply-To: <243F061D-CAD2-49DA-93A4-A44943AF6707@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Following up on SED data types from today's design call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:11:21 -0000 Hi Dean I agree with point 1. Regarding point 2, the SPID is still the problem. You have shown two option= s, Next-hop URI and transformation - but how about the "non-next-hop" URI a= s in the case of a URI being used basically as an opaque string (e.g. SPID)= ?=20 Does anyone remember why we went with a URI and not a URN for the SPID use = case? Wouldn't a URN solve the problem? i.e.. have 3 types... URI, URN and = transformation... :D On Apr 5, 2012, at 4:05 AM, Dean Willis wrote: >=20 > David S. sent out an email before the call today that proposed an abstrac= ted restructuring of the Route Record into a SED Type, with subtypes Locati= on and Target. >=20 > Discussion on today's call seemed to reveal that we might be able to addr= ess his concerns with something simpler.=20 >=20 > I think we've been getting tangled up between the two basic questions abo= ut SED data: >=20 > 1) What is the data?=20 > Is it a SIP URI?=20 > An NS record?=20 > A NAPTR record?=20 > A routing number?=20 > A SPID?=20 > An XMPP URI? > A tel: URI? > An H.323 URI? > An arbitrary string? > A template to which we apply a regex transform using the >=20 > 2) What are we supposed to DO with the data once, we have it in hand? > Route the request there? > Retarget the call to that destination? > Use the service indicated by the SED data to look up a next action? > Use the SED data as a key into some other routing database >=20 >=20 > I'd argue that most of the "What is it" problems become moot if we simple= say "It's a URI", because examination of a naked URI tells us a lot about = the encoded data. We know to use a SIP URI with SIP, an XMPP URI with XMPP,= and so on. For NSType and NAPTRType, we have RFC 4501 "Domain Name System = Uniform Resource Identifiers". We probably also need an optional regular ex= pression for further processing of the SED data. >=20 > So if we answer #1 by saying "It's a URI, dude! And it might have a regex= with it!" we have answered half the question space. This might not cover S= PIDs (still a standards-undefined-thing) and telephone number ranges (which= are partially specified in RFC 3966). But it does cover the cases in draft= -ietf-drinks-spp-framework-01. >=20 > As for question #2: >=20 > David seems to think that there are are a couple of roles for SED data, m= ostly using RFC 5486 terms, and that we need to tell the recipient of the S= ED data how to use that data; that is, what the role of the data is. So far= , this makes sense to me. The next step is where it gets fuzzy.... >=20 > We seem to have: >=20 > LUF, which we query for a new target domain to which we should route the = request. I THINK David called this a TargetType in his morning email. >=20 > LRF, which we query for a signaling-function to which we will send the a= ctual request. I THINK David called this a LocationType in his morning emai= l. >=20 > SPID, which we somehow use magically as sort of a LUF for an LRF; in othe= r words, we use the SPID to find a LUF which will give us an LRF. >=20 > RN, or routing number, which seems to work like a SPID but is itself a ph= one number. >=20 >=20 > I'm not sure this makes sense, either. Then again, the subtlety of LRF an= d LUF has always escaped me. A SIP proxy in domain X might route an INVITE,= or it might redirect it, and in either case the "target" might be in domai= ns X or Y, and if you send it a request, you have to be prepared for it to = do either. >=20 >=20 > I think instead we have two possible "types" of responses. >=20 > 1) A next-hop URI. If it's the sort of URI that gets queried (NS), the us= er queries it. If it's the sort of URI that you send the request to and it = routes or redirects (SIP, XMPP), the user sends the request to it, and the = right thing happens. Given a URI, why does a user need to know whether it's= an LUF or an LRF? >=20 > 2) A transformation. The user takes the response, applies it to the exist= ing data using a regex-replacement, and tries again. >=20 >=20 > In the framework, this "transformation" is muddled up in a combination of= the URIRteRecType (framework-01, bottom of page 33) and its pattern,= and the EgrRteType (framework-01, page 38). This confuses me beyond all co= mprehension. >=20 >=20 > Could we solve the whole can of worms by replacing "Egress Route" and "Ro= ute Record" with a "SED Record" containing the base type plus a URI plus a = regex? >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From dean.willis@softarmor.com Tue Apr 10 09:55:31 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CEA21F8688 for ; Tue, 10 Apr 2012 09:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0gYFgEWuQOV for ; Tue, 10 Apr 2012 09:55:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D20E521F8680 for ; Tue, 10 Apr 2012 09:55:29 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so10150obb.31 for ; Tue, 10 Apr 2012 09:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bXuAWiDrD244BOyGdUIW9NIRAXvSqQZkZJGy5tiPxI8=; b=QybJ8w6ZOH8rHqkvFR8l1UaxQJJf3ERQE3iOn8ahnqYmttfsM71oz7YkRjXSWpgxvR 8WH303IAQ9O1SsOwWD7rYWv7Fr90VFuUSIoelaeuSbHfGgX3l1ZnqlRVZ8CXkmtWWs2l +COEjY72M6fONCm1930ngX2MYEgXgXf9gdt1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bXuAWiDrD244BOyGdUIW9NIRAXvSqQZkZJGy5tiPxI8=; b=VGCVjo6OmMJrd2SAWgyExomHIsG2yFtCXv5Ju9nS6F/SGqN6VQ+EhZks0GlooEkBvt iM1OcYmkInp1omkuf+p/L9l4aBM+Eprw1HDYAdCdrSaVI80zeJm6LOOdyrFoZWic/6tZ 4WEjyQgOyymIem5Z9sfJSEteDavslJWM3dpChd6Q5rpVtlf2IQD8MME0Q+LbfZRBKJjA x2Bmuo9/VeCD4iwuensNb2BAV7+RJpPqL/3cvWselVg7FRjgKdW5MxRYpoYcsgLoTl61 lmw/2/7Vb5h/h2s4VhWhAX3E2eZnWPzXXGlWRggBG+LyP8vIS3YHbOYNt4bYPmk3Lerz PTeA== MIME-Version: 1.0 Received: by 10.182.188.38 with SMTP id fx6mr16885852obc.77.1334076929204; Tue, 10 Apr 2012 09:55:29 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Tue, 10 Apr 2012 09:55:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 11:55:29 -0500 Message-ID: From: Dean Willis To: David Schwartz Content-Type: multipart/alternative; boundary=f46d04478bdd77e3c704bd55fd77 X-Gm-Message-State: ALoCoQkiQ+14oNR5DVq1Yw1a3OMpSiEiR8C7EBRwv+KKJgH0NHdSYXRNnxypSzSj9+ttgJiok7SO Cc: "drinks@ietf.org" Subject: Re: [drinks] What do we mean by "peering"? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:55:31 -0000 --f46d04478bdd77e3c704bd55fd77 Content-Type: text/plain; charset=ISO-8859-1 I'm finding that "target" has been heavily overloaded; we have the OMA version, the 3GPP version, Christer's version, old SIP text, and so on. So I'm confused. What is the difference between routing and targeting (and retargeting) in your world view? On Thu, Apr 5, 2012 at 3:29 AM, David Schwartz wrote: > Hi Dean > > I am ok with your proposal. Here is a slight modification of the second > paragraph... > > The SED described in this framework is limited to simple routing *** and > targeting *** data. Although the terms "peer" and "peering" are used, these > refer only to the sharing of basic call routing *** and targeting *** > information between users of the registry, and do not address the broad > range of policy factors that might be used in a commercial peering > "clearinghouse" operation. In short "peering organizations" are other users > of the same registry, and "peers" are users of that registry to whom the > offer of sharing specific SED has been extended, and who have accepted that > offer. > > :D > > > On Apr 5, 2012, at 4:57 AM, Dean Willis wrote: > > > Peering seems to be a very loaded term. When David explains it to me, it > seems it means to him a whole lot of business-specific rules related to the > routes along which calls can be made. It includes things like time-of-day, > pricing, periodic contractual commitments with different rates, available > bandwidth, available QoS, SLAs and all those myriad things that make up the > black magic of the "policy server". > > > We have a much simpler view of "peering" in the framework document. Here, > we merely concerned with the sharing of routes. We have a route, we offer > it to someone, and if they accept the route, it will appear when they > appropriately query the engine that access our data (although how said > database determines query-identity/authority using the information in the > database seems to be perplexingly out of scope). > > But in short, what we're really talking about is a sort of per-route > access-control list that has two facets: the "Is allowed to see this route" > facet, and the dependent "wants to see this route in its responses" facet. > As far as I can tell, we don't even have a way to retract permission once > granted; the only option is to to retract a route accepted by example.comis to delete the route, then re-offer it to everybody on the old list > except example. com, then wait for them to accept the "new" route. > Personally this seems like a clusterpluck, but it's what we agreed to. > > > While we could certainly quibble forever on cleaning up this semantics in > the protocol (and end up with the "Session Establishment Data Sharing > Protocol), it's been proposed that we don't need to, and that all we need > to do is to explain this concept of "peering by sharing routes" succinctly > within the draft. > > > Let me try by re-writing the introduction: > > > 1. Introduction > > Service providers and enterprises use registries to make session routing > decisions for Voice over IP, SMS and MMS traffic exchanges. This document > is narrowly focused on the provisioning framework for these registries. In > other words, the goal is to allow users to put session establishment data > (SED) into a registry, to share that SED selectively with other users of > that registry, and to allow those other users to further select a subset of > that SED for use in their own applications. The requirements and use cases > driving this framework have been documented in [RFC6461 ], and the reader > is expected to be familiar with the terminology defined therein. > > The SED described in this framework is limited to simple routing data. > Although the terms "peer" and "peering" are used, these refer only to the > sharing of basic call routing information between users of the registry, > and do not address the broad range of policy factors that might be used in > a commercial peering "clearinghouse" operation. In short "peering > organizations" are other users of the same registry, and "peers" are users > of that registry to whom the offer of sharing specific SED has been > extended, and who have accepted that offer. > > Three types of data flows are described in [RFC 6471]: client to/from > registry, registry to local data repository and registry to registry, as > shown here: > > > > *--------* *------------* *------------* > | | (1). Client | | (3).Registry | | > | Client | <-----------> | Registry |<------------->| Registry | > | | to Registry | | to Registry | | > *--------* *------------* *------------* > / \ \ > / \ \ > / \ \ > / \ v > / \ ... > / \ > / (2). Distrib \ > / Registry data \ > / to local data \ > V store V > +----------+ +----------+ > |Local Data| |Local Data| > |Repository| |Repository| > +----------+ +----------+ > > Three Registry Provisioning Flows > > > This document addresses only the (1) Client to Registry aspect. This > document defines an abstract framework for the interaction of registry > clients with registries, referred to as the Session Peering Provisioning > Framework (SPPF). This abstract framework is to be mapped into specific > protocol bindings in other documents, initially to SOAP in > [draft-ietf-drinks-spp-soap]. > > The data provisioned for session establishment is typically used > by various downstream SIP signaling systems to route a call to the next hop > associated with the called domain. These systems typically use a local > data store ("Local Data Repository") as their source of session routing > information. More specifically, the SED data is the set of parameters that > the outgoing signaling path border elements (SBEs) need to initiate the > session. See [RFC5486] for more details. > > A "terminating" SIP Service Provider (SSP) provisions SED into > the registry to be selectively shared with other SSPs. Subsequently, a > registry may distribute the provisioned data into local data repositories > used for look-up queries (identifier -> URI) or for lookup and location > resolution (identifier -> URI -> ingress SBE of terminating SSP). In some > cases, the registry may additionally offer a central query resolution > service (not shown in the above figure). Typically, this query resolution > service will be something like an ENUM [RFC 3761] server or a SIP [RFC > 3261] proxy or redirect server. > > The roles of "client" and "server" are abstract and only apply to the > requesting and responding roles in given transactions and are not related > in any way to the type of entity participating in a protocol exchange. For > example, a registry might also include a "client" when such a registry > initiates a connection (for example, for data distribution to an SSP). > > ... continue with existing text from "A key requirement..." > > > > --f46d04478bdd77e3c704bd55fd77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm finding that "target" has been heavily overloaded; we hav= e the OMA version, the 3GPP version, Christer's version, old SIP text, = and so on.

So I'm confused.

What is the difference between routing and targeting (and retargeting) in y= our world view?


On Thu, Apr 5,= 2012 at 3:29 AM, David Schwartz <dschwartz@xconnect.net> wrote:
Hi Dean<= div>
I am ok with your proposal. Here is a slight modificatio= n of the second paragraph...

The SED described in this framework is limited to simpl= e routing *** and targeting *** data. Although the terms "peer" a= nd "peering" are used, these refer only to the sharing of basic c= all routing *** and targeting *** information between users of the registry= , and do not address the broad range of policy factors that might be used i= n a commercial peering "clearinghouse" operation. In short "= peering organizations" are other users of the same registry, and "= ;peers" are users of that registry to whom the offer of sharing specif= ic SED has been extended, and who have accepted that offer.

:D


On Apr 5, 2012, at 4:57 AM, Dean Willis wrote:


Peering seems to be a very loaded term. When David expl= ains it to me, it seems it means to him a whole lot of business-specific ru= les related to the routes along which calls can be made. It includes things= like time-of-day, pricing, periodic contractual commitments with different= rates, available bandwidth, available QoS, SLAs and all those myriad thing= s that make up the black magic of the "policy server".


We have a much simpler view of "pee= ring" in the framework document. Here, we merely concerned with the sh= aring of routes. We have a route, we offer it to someone, and if they accep= t the route, it will appear when they appropriately query the engine that a= ccess our data (although how said database determines query-identity/author= ity using the information in the database seems to be perplexingly out of s= cope).

But in short, what we're really talking about is a = sort of per-route access-control list that has two facets: the "Is all= owed to see this route" facet, and the dependent "wants to see th= is route in its responses" facet. As far as I can tell, we don't e= ven have a way to retract permission once granted; the only option is to to= retract a route accepted by example.com is to delete the route, then re-offer it to everybody o= n the old list except example. com, then wait for them to accept the "= new" route. Personally this seems like a clusterpluck, but it's wh= at we agreed to.


While we could certainly quibble forever= on cleaning up this semantics in the protocol (and end up with the "S= ession Establishment Data Sharing Protocol), it's been proposed that we= don't need to, and that all we need to do is to explain this concept o= f "peering by sharing routes" succinctly within the draft.


Let me try by re-writing the introductio= n:


1. =A0Introduction

Service providers and enterprises use registries to make session=A0ro= uting decisions for Voice over IP, SMS and MMS traffic exchanges.=A0This do= cument is narrowly focused on the provisioning framework for=A0these regist= ries. =A0In other words, the goal is to allow users to put session establis= hment data (SED) into a registry, to share that SED selectively with other = users of that registry, and to allow those other users to further select a = subset of that SED for use in their own applications.=A0=A0The requirements= and use cases driving this framework have=A0been documented in [RFC6461=A0= ], and the reader is expected to be familiar=A0with the terminology defined= therein.

The SED described in this framework is limited to simpl= e routing data. Although the terms "peer" and "peering"= are used, these refer only to the sharing of basic call routing informatio= n between users of the registry, and do not address the broad range of poli= cy factors that might be used in a commercial peering "clearinghouse&q= uot; operation. In short "peering organizations" are other users = of the same registry, and "peers" are users of that registry to w= hom the offer of sharing specific SED has been extended, and who have accep= ted that offer.

Three types of data flows are described in [RFC 6471]: = client to/from registry, registry to local data=A0repository and registry t= o registry, as shown here:



=A0 =A0 *--------* =A0 =A0 =A0 =A0= =A0 =A0 =A0 *------------* =A0 =A0 =A0 =A0 =A0 =A0 =A0 *------------*
=A0 =A0 | =A0 =A0 =A0 =A0| (1). Client = =A0 | =A0 =A0 =A0 =A0 =A0 =A0| (3).Registry =A0| =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 | Client | <-----------> | =A0Reg= istry =A0|<------------->| =A0Registry =A0|
=A0 =A0 | =A0 =A0 =A0 =A0| =A0 to Registry | =A0 =A0 =A0 =A0= =A0 =A0| =A0to Registry =A0| =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 *--------* =A0 =A0 =A0 =A0 =A0 =A0 =A0 = *------------* =A0 =A0 =A0 =A0 =A0 =A0 =A0 *------------*
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 / =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 / =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0\
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0v
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0= =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / (2). Distrib = \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0/ Registry data =A0\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 / =A0to local data =A0 \
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V =A0 =A0 =A0store =A0 =A0 = =A0 =A0 V
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 +----------+ =A0 =A0 =A0 +----------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= |Local Data| =A0 =A0 =A0 |Local Data|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |Repository| =A0 =A0 = =A0 |Repository|
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +----------+ =A0 =A0 =A0 +----------+

= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Three Registry Provisioning Flow= s


This document addres= ses only the (1) Client=A0to Registry aspect.=A0 This document defines an a= bstract framework for the interaction of registry clients with registries, = referred to=A0as the Session Peering Provisioning Framework (SPPF). =A0This= abstract framework is to be mapped into specific protocol bindings in othe= r documents, initially to SOAP in [draft-ietf-drinks-spp-soap].

The data provisioned for session establishment is typic= ally used by=A0various downstream SIP signaling systems to route a call to = the next=A0hop associated with the called domain. =A0These systems typicall= y use a=A0local data store ("Local Data Repository") as their sou= rce of session=A0routing information. =A0More specifically, the SED data is= the set of=A0parameters that the outgoing signaling path border elements (= SBEs)=A0need to initiate the session. =A0See [RFC5486] for more details.

A "terminating" SIP Service Provid= er (SSP) provisions SED into the=A0registry to be selectively shared with o= ther SSPs.=A0Subsequently, a registry may distribute the provisioned data i= nto=A0local data repositories used for look-up queries (identifier -> UR= I)=A0or for lookup and location resolution (identifier -> URI -> ingr= ess=A0SBE of terminating SSP). =A0In some cases, the registry may=A0additio= nally offer a central query resolution service (not shown in=A0the above fi= gure). Typically, this query resolution service will be something like an E= NUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server.

The roles of =A0"client" and "server" ar= e abstract and only apply to the requesting and responding roles in given t= ransactions and are not related in any way to the type of entity participat= ing in a protocol exchange. =A0For example, a=A0registry might also include= a "client" when such a registry initiates a connection (for exam= ple, for data distribution to an SSP).

... continue with existing text from "A key requir= ement..."
<ATT00001..c>


--f46d04478bdd77e3c704bd55fd77-- From dean.willis@softarmor.com Tue Apr 10 09:56:57 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AB111E80EA for ; Tue, 10 Apr 2012 09:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDghclGSz+0C for ; Tue, 10 Apr 2012 09:56:56 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3D821F863E for ; Tue, 10 Apr 2012 09:56:56 -0700 (PDT) Received: by ggmi1 with SMTP id i1so7212ggm.31 for ; Tue, 10 Apr 2012 09:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GlOgzIft+E7QZptpu4FBhmfojTQKXY2+p56pneRrw78=; b=RaYj+w4tp6gTsv5HWlRzSJnMP2Sr8/oYHDoT+0zzydTRiZ25cskjT702gLtgNceu5y aPR8fR1++UmQu4Vl+GuEVH8vPW1LaUxc6uB3frxYlosCx6B5eRjRgg5pLI3YSrynvKow w1nS+vIM6Wno7dmGlRowbjNoij/oXw4GMjYyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=GlOgzIft+E7QZptpu4FBhmfojTQKXY2+p56pneRrw78=; b=Hb1s3+EAfT99hS99eRihD9D/QZmtzFgawzv1zJKsLot58RS8ncFzl3kFX0SrfsoBck yo10N+y+ht+/YwH8wv9WQeeffqejoxbpO5FwvA9mm95oMomIWz+NCwDsWAVGflMnVa9k 0DCI/9hZPugbfnnZknR6q3dPcyKePKTp+0RfM6YWw/E7ALeI5M2XRDDTM7sZlncX3Gw5 r0tvfeO6jXrvlYyrwyC+06iCTV+tyWqhaMjMH7E31RRg4Zn9r937m0h/XChR+pZPPyz2 Llbt8EIj6bIdkzpi1qY7GsXoIY048Sfa/sfiBJq35QMXHDKLfVW+Q/eq8cuEuvk1bMxJ Q8FQ== MIME-Version: 1.0 Received: by 10.60.12.162 with SMTP id z2mr16811446oeb.47.1334077015704; Tue, 10 Apr 2012 09:56:55 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Tue, 10 Apr 2012 09:56:55 -0700 (PDT) In-Reply-To: <48B10C7B-57AD-47AF-93BE-AF667D926E0A@xconnect.net> References: <243F061D-CAD2-49DA-93A4-A44943AF6707@softarmor.com> <48B10C7B-57AD-47AF-93BE-AF667D926E0A@xconnect.net> Date: Tue, 10 Apr 2012 11:56:55 -0500 Message-ID: From: Dean Willis To: David Schwartz Content-Type: multipart/alternative; boundary=e89a8f83a03b9fc60504bd56023a X-Gm-Message-State: ALoCoQnJeoOuVHVIjILVOh6NqV89Ru/1i/GD0lJ/xyoSYGthehUPWAMJRumw2GUDuwjSj+LKTIkv Cc: "drinks@ietf.org" Subject: Re: [drinks] Following up on SED data types from today's design call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:56:57 -0000 --e89a8f83a03b9fc60504bd56023a Content-Type: text/plain; charset=ISO-8859-1 You may recall there's another IETF thread on defining SPID or something like it. We're sortof stuck on a "standard" representation for SPID until that completes, although one would hop it a UR-something. On Thu, Apr 5, 2012 at 4:11 AM, David Schwartz wrote: > Hi Dean > > I agree with point 1. > > Regarding point 2, the SPID is still the problem. You have shown two > options, Next-hop URI and transformation - but how about the "non-next-hop" > URI as in the case of a URI being used basically as an opaque string (e.g. > SPID)? > > Does anyone remember why we went with a URI and not a URN for the SPID use > case? Wouldn't a URN solve the problem? i.e.. have 3 types... URI, URN and > transformation... > > :D > > On Apr 5, 2012, at 4:05 AM, Dean Willis wrote: > > > > > David S. sent out an email before the call today that proposed an > abstracted restructuring of the Route Record into a SED Type, with subtypes > Location and Target. > > > > Discussion on today's call seemed to reveal that we might be able to > address his concerns with something simpler. > > > > I think we've been getting tangled up between the two basic questions > about SED data: > > > > 1) What is the data? > > Is it a SIP URI? > > An NS record? > > A NAPTR record? > > A routing number? > > A SPID? > > An XMPP URI? > > A tel: URI? > > An H.323 URI? > > An arbitrary string? > > A template to which we apply a regex transform using the > > > > 2) What are we supposed to DO with the data once, we have it in hand? > > Route the request there? > > Retarget the call to that destination? > > Use the service indicated by the SED data to look up a next action? > > Use the SED data as a key into some other routing database > > > > > > I'd argue that most of the "What is it" problems become moot if we > simple say "It's a URI", because examination of a naked URI tells us a lot > about the encoded data. We know to use a SIP URI with SIP, an XMPP URI with > XMPP, and so on. For NSType and NAPTRType, we have RFC 4501 "Domain Name > System Uniform Resource Identifiers". We probably also need an optional > regular expression for further processing of the SED data. > > > > So if we answer #1 by saying "It's a URI, dude! And it might have a > regex with it!" we have answered half the question space. This might not > cover SPIDs (still a standards-undefined-thing) and telephone number ranges > (which are partially specified in RFC 3966). But it does cover the cases in > draft-ietf-drinks-spp-framework-01. > > > > As for question #2: > > > > David seems to think that there are are a couple of roles for SED data, > mostly using RFC 5486 terms, and that we need to tell the recipient of the > SED data how to use that data; that is, what the role of the data is. So > far, this makes sense to me. The next step is where it gets fuzzy.... > > > > We seem to have: > > > > LUF, which we query for a new target domain to which we should route the > request. I THINK David called this a TargetType in his morning email. > > > > LRF, which we query for a signaling-function to which we will send the > actual request. I THINK David called this a LocationType in his morning > email. > > > > SPID, which we somehow use magically as sort of a LUF for an LRF; in > other words, we use the SPID to find a LUF which will give us an LRF. > > > > RN, or routing number, which seems to work like a SPID but is itself a > phone number. > > > > > > I'm not sure this makes sense, either. Then again, the subtlety of LRF > and LUF has always escaped me. A SIP proxy in domain X might route an > INVITE, or it might redirect it, and in either case the "target" might be > in domains X or Y, and if you send it a request, you have to be prepared > for it to do either. > > > > > > I think instead we have two possible "types" of responses. > > > > 1) A next-hop URI. If it's the sort of URI that gets queried (NS), the > user queries it. If it's the sort of URI that you send the request to and > it routes or redirects (SIP, XMPP), the user sends the request to it, and > the right thing happens. Given a URI, why does a user need to know whether > it's an LUF or an LRF? > > > > 2) A transformation. The user takes the response, applies it to the > existing data using a regex-replacement, and tries again. > > > > > > In the framework, this "transformation" is muddled up in a combination > of the URIRteRecType (framework-01, bottom of page 33) and its > pattern, and the EgrRteType (framework-01, page 38). This confuses me > beyond all comprehension. > > > > > > Could we solve the whole can of worms by replacing "Egress Route" and > "Route Record" with a "SED Record" containing the base type plus a URI plus > a regex? > > > > -- > > Dean > > > > > > > > > > > > > > _______________________________________________ > > drinks mailing list > > drinks@ietf.org > > https://www.ietf.org/mailman/listinfo/drinks > > --e89a8f83a03b9fc60504bd56023a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You may recall there's another IETF thread on defining SPID or somethin= g like it. We're sortof stuck on a "standard" representation = for SPID until that completes, although one would hop it a UR-something.
On Thu, Apr 5, 2012 at 4:11 AM, David Schwar= tz <dschwart= z@xconnect.net> wrote:
Hi Dean

I agree with point 1.

Regarding point 2, the SPID is still the problem. You have shown two option= s, Next-hop URI and transformation - but how about the "non-next-hop&q= uot; URI as in the case of a URI being used basically as an opaque string (= e.g. SPID)?

Does anyone remember why we went with a URI and not a URN for the SPID use = case? Wouldn't a URN solve the problem? i.e.. have 3 types... URI, URN = and transformation...

:D

On Apr 5, 2012, at 4:05 AM, Dean Willis wrote:

>
> David S. sent out an email before the call today that proposed an abst= racted restructuring of the Route Record into a SED Type, with subtypes Loc= ation and Target.
>
> Discussion on today's call seemed to reveal that we might be able = to address his concerns with something simpler.
>
> I think we've been getting tangled up between the two basic questi= ons about SED data:
>
> 1) What is the data?
> =A0 =A0 =A0 Is it a SIP URI?
> =A0 =A0 =A0 An NS record?
> =A0 =A0 =A0 A NAPTR record?
> =A0 =A0 =A0 A routing number?
> =A0 =A0 =A0 A SPID?
> =A0 =A0 =A0 An XMPP URI?
> =A0 =A0 =A0 A tel: URI?
> =A0 =A0 =A0 An H.323 URI?
> =A0 =A0 =A0 An arbitrary string?
> =A0 =A0 =A0 A template to which we apply a regex transform using the >
> 2) What are we supposed to DO with the data once, we have it in hand?<= br> > =A0 =A0 =A0 Route the request there?
> =A0 =A0 =A0 Retarget the call to that destination?
> =A0 =A0 =A0 Use the service indicated by the SED data to look up a nex= t action?
> =A0 =A0 =A0 Use the SED data as a key into some other routing database=
>
>
> I'd argue that most of the "What is it" problems become = moot if we simple say "It's a URI", because examination of a = naked URI tells us a lot about the encoded data. We know to use a SIP URI w= ith SIP, an XMPP URI with XMPP, and so on. For NSType and NAPTRType, we hav= e RFC 4501 "Domain Name System Uniform Resource Identifiers". We = probably also need an optional regular expression for further processing of= the SED data.
>
> So if we answer #1 by saying "It's a URI, dude! And it might = have a regex with it!" we have answered half the question space. This = might not cover SPIDs (still a standards-undefined-thing) and telephone num= ber ranges (which are partially specified in RFC 3966). But it does cover t= he cases in draft-ietf-drinks-spp-framework-01.
>
> As for question #2:
>
> David seems to think that there are are a couple of roles for SED data= , mostly using RFC 5486 terms, and that we need to tell the recipient of th= e SED data how to use that data; that is, what the role of the data is. So = far, this makes sense to me. The next step is where it gets fuzzy....
>
> We seem to have:
>
> LUF, which we query for a new target domain to which we should route t= he request. =A0I THINK David called this a TargetType in his morning email.=
>
> LRF, which we =A0query for a signaling-function to which we will send = the actual request. I THINK David called this a LocationType in his morning= email.
>
> SPID, which we somehow use magically as sort of a LUF for an LRF; in o= ther words, we use the SPID to find a LUF which will give us an LRF.
>
> RN, or routing number, which seems to work like a SPID but is itself a= phone number.
>
>
> I'm not sure this makes sense, either. Then again, the subtlety of= LRF and LUF has always escaped me. A SIP proxy in domain X might route an = INVITE, or it might redirect it, and in either case the "target" = might be in domains X or Y, and if you send it a request, you have to be pr= epared for it to do either.
>
>
> I think instead we have two possible "types" of responses. >
> 1) A next-hop URI. If it's the sort of URI that gets queried (NS),= the user queries it. If it's the sort of URI that you send the request= to and it routes or redirects (SIP, XMPP), the user sends the request to i= t, and the right thing happens. Given a URI, why does a user need to know w= hether it's an LUF or an LRF?
>
> 2) A transformation. The user takes the response, applies it to the ex= isting data using a regex-replacement, and tries again.
>
>
> In the framework, this "transformation" is muddled up in a c= ombination of the URIRteRecType (framework-01, bottom of page 33) and its &= lt;ere> pattern, and the EgrRteType (framework-01, page 38). This confus= es me beyond all comprehension.
>
>
> Could we solve the whole can of worms by replacing "Egress Route&= quot; and "Route Record" with a "SED Record" containing= the base type plus a URI plus a regex?
>
> --
> Dean
>
>
>
>
>
>
> _______________________________________________
> drinks mailing list
> drinks@ietf.org
> https://www.ietf.org/mailman/listinfo/drinks


--e89a8f83a03b9fc60504bd56023a-- From dschwartz@xconnect.net Tue Apr 10 12:24:22 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFCE11E80DF for ; Tue, 10 Apr 2012 12:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTtEEYWTZlxY for ; Tue, 10 Apr 2012 12:24:21 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id AFE2021F8636 for ; Tue, 10 Apr 2012 12:24:20 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Tue, 10 Apr 2012 22:24:18 +0300 From: David Schwartz To: Dean Willis Date: Tue, 10 Apr 2012 22:24:18 +0300 Thread-Topic: [drinks] What do we mean by "peering"? Thread-Index: Ac0XT4XITAErhdEUR5aLLFzlvRmgGg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A30A2B47A4384D298298B7F87F9CADA5xconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] What do we mean by "peering"? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:24:22 -0000 --_000_A30A2B47A4384D298298B7F87F9CADA5xconnectnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be honest I never liked the term "target" but it was the only one we cou= ld agree on. To me, the target is basically the NON-ROUTABLE name or identi= ty of the party or entity claiming ownership (i.e. can terminate a call to)= of an e.164 identifier - WHO not WHERE. The sticky part was dealing with t= he whole transit issue, and the use of "target" was an attempt to disambigu= ate this issue. :D On Apr 10, 2012, at 7:55 PM, Dean Willis wrote: I'm finding that "target" has been heavily overloaded; we have the OMA vers= ion, the 3GPP version, Christer's version, old SIP text, and so on. So I'm confused. What is the difference between routing and targeting (and retargeting) in y= our world view? On Thu, Apr 5, 2012 at 3:29 AM, David Schwartz > wrote: Hi Dean I am ok with your proposal. Here is a slight modification of the second par= agraph... The SED described in this framework is limited to simple routing *** and ta= rgeting *** data. Although the terms "peer" and "peering" are used, these r= efer only to the sharing of basic call routing *** and targeting *** inform= ation between users of the registry, and do not address the broad range of = policy factors that might be used in a commercial peering "clearinghouse" o= peration. In short "peering organizations" are other users of the same regi= stry, and "peers" are users of that registry to whom the offer of sharing s= pecific SED has been extended, and who have accepted that offer. :D On Apr 5, 2012, at 4:57 AM, Dean Willis wrote: Peering seems to be a very loaded term. When David explains it to me, it se= ems it means to him a whole lot of business-specific rules related to the r= outes along which calls can be made. It includes things like time-of-day, p= ricing, periodic contractual commitments with different rates, available ba= ndwidth, available QoS, SLAs and all those myriad things that make up the b= lack magic of the "policy server". We have a much simpler view of "peering" in the framework document. Here, w= e merely concerned with the sharing of routes. We have a route, we offer it= to someone, and if they accept the route, it will appear when they appropr= iately query the engine that access our data (although how said database de= termines query-identity/authority using the information in the database see= ms to be perplexingly out of scope). But in short, what we're really talking about is a sort of per-route access= -control list that has two facets: the "Is allowed to see this route" facet= , and the dependent "wants to see this route in its responses" facet. As fa= r as I can tell, we don't even have a way to retract permission once grante= d; the only option is to to retract a route accepted by example.com is to delete the route, then re-offer it to everybody on the = old list except example. com, then wait for them to accept the "new" route.= Personally this seems like a clusterpluck, but it's what we agreed to. While we could certainly quibble forever on cleaning up this semantics in t= he protocol (and end up with the "Session Establishment Data Sharing Protoc= ol), it's been proposed that we don't need to, and that all we need to do i= s to explain this concept of "peering by sharing routes" succinctly within = the draft. Let me try by re-writing the introduction: 1. Introduction Service providers and enterprises use registries to make session routing de= cisions for Voice over IP, SMS and MMS traffic exchanges. This document is = narrowly focused on the provisioning framework for these registries. In ot= her words, the goal is to allow users to put session establishment data (SE= D) into a registry, to share that SED selectively with other users of that = registry, and to allow those other users to further select a subset of that= SED for use in their own applications. The requirements and use cases dri= ving this framework have been documented in [RFC6461 ], and the reader is e= xpected to be familiar with the terminology defined therein. The SED described in this framework is limited to simple routing data. Alth= ough the terms "peer" and "peering" are used, these refer only to the shari= ng of basic call routing information between users of the registry, and do = not address the broad range of policy factors that might be used in a comme= rcial peering "clearinghouse" operation. In short "peering organizations" a= re other users of the same registry, and "peers" are users of that registry= to whom the offer of sharing specific SED has been extended, and who have = accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from regis= try, registry to local data repository and registry to registry, as shown h= ere: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This docum= ent defines an abstract framework for the interaction of registry clients w= ith registries, referred to as the Session Peering Provisioning Framework (= SPPF). This abstract framework is to be mapped into specific protocol bind= ings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by various= downstream SIP signaling systems to route a call to the next hop associate= d with the called domain. These systems typically use a local data store (= "Local Data Repository") as their source of session routing information. M= ore specifically, the SED data is the set of parameters that the outgoing s= ignaling path border elements (SBEs) need to initiate the session. See [RF= C5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the registry= to be selectively shared with other SSPs. Subsequently, a registry may dis= tribute the provisioned data into local data repositories used for look-up = queries (identifier -> URI) or for lookup and location resolution (identifi= er -> URI -> ingress SBE of terminating SSP). In some cases, the registry = may additionally offer a central query resolution service (not shown in the= above figure). Typically, this query resolution service will be something = like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server= . The roles of "client" and "server" are abstract and only apply to the requ= esting and responding roles in given transactions and are not related in an= y way to the type of entity participating in a protocol exchange. For exam= ple, a registry might also include a "client" when such a registry initiate= s a connection (for example, for data distribution to an SSP). ... continue with existing text from "A key requirement..." --_000_A30A2B47A4384D298298B7F87F9CADA5xconnectnet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To be honest I never liked= the term "target" but it was the only one we could agree on. To me, the ta= rget is basically the NON-ROUTABLE name or identity of the party or entity = claiming ownership (i.e. can terminate a call to) of an e.164 identifier - = WHO not WHERE. The sticky part was dealing with the whole transit issue, an= d the use of "target" was an attempt to disambiguate this issue.

:D

On Apr 10, 2012, at 7:55 PM, D= ean Willis wrote:

I'm finding that "target" has been heavily overloaded; we hav= e the OMA version, the 3GPP version, Christer's version, old SIP text, and = so on.

So I'm confused.

What is the difference between routing and targeting (and retargeting) in y= our world view?


On Thu, Apr 5,= 2012 at 3:29 AM, David Schwartz <dschwartz@xconnect.net> wrote:
Hi Dean<= div>
I am ok with your proposal. Here is a slight modificatio= n of the second paragraph...

The SED described in this framework is limited to simpl= e routing *** and targeting *** data. Although the terms "peer" and "peerin= g" are used, these refer only to the sharing of basic call routing *** and = targeting *** information between users of the registry, and do not address= the broad range of policy factors that might be used in a commercial peeri= ng "clearinghouse" operation. In short "peering organizations" are other us= ers of the same registry, and "peers" are users of that registry to whom th= e offer of sharing specific SED has been extended, and who have accepted th= at offer.

:D


On Apr 5, 2012, at 4:57 AM, Dean Willis wrote:


Peering seems to be a very loaded term. When David expl= ains it to me, it seems it means to him a whole lot of business-specific ru= les related to the routes along which calls can be made. It includes things= like time-of-day, pricing, periodic contractual commitments with different= rates, available bandwidth, available QoS, SLAs and all those myriad thing= s that make up the black magic of the "policy server".


We have a much simpler view of "peering"= in the framework document. Here, we merely concerned with the sharing of r= outes. We have a route, we offer it to someone, and if they accept the rout= e, it will appear when they appropriately query the engine that access our = data (although how said database determines query-identity/authority using = the information in the database seems to be perplexingly out of scope).

But in short, what we're really talking about is a sort= of per-route access-control list that has two facets: the "Is allowed to s= ee this route" facet, and the dependent "wants to see this route in its res= ponses" facet. As far as I can tell, we don't even have a way to retract pe= rmission once granted; the only option is to to retract a route accepted by= example.com is to de= lete the route, then re-offer it to everybody on the old list except exampl= e. com, then wait for them to accept the "new" route. Personally this seems= like a clusterpluck, but it's what we agreed to.


While we could certainly quibble forever= on cleaning up this semantics in the protocol (and end up with the "Sessio= n Establishment Data Sharing Protocol), it's been proposed that we don't ne= ed to, and that all we need to do is to explain this concept of "peering by= sharing routes" succinctly within the draft.


Let me try by re-writing the introductio= n:


1.  Introduction

Service providers and enterprises use registries to make session&n= bsp;routing decisions for Voice over IP, SMS and MMS traffic exchanges.&nbs= p;This document is narrowly focused on the provisioning framework for = these registries.  In other words, the goal is to allow users to put s= ession establishment data (SED) into a registry, to share that SED selectiv= ely with other users of that registry, and to allow those other users to fu= rther select a subset of that SED for use in their own applications. &= nbsp;The requirements and use cases driving this framework have been d= ocumented in [RFC6461 ], and the reader is expected to be familiar&nbs= p;with the terminology defined therein.

The SED described in this framework is limited to simpl= e routing data. Although the terms "peer" and "peering" are used, these ref= er only to the sharing of basic call routing information between users of t= he registry, and do not address the broad range of policy factors that migh= t be used in a commercial peering "clearinghouse" operation. In short "peer= ing organizations" are other users of the same registry, and "peers" are us= ers of that registry to whom the offer of sharing specific SED has been ext= ended, and who have accepted that offer.

Three types of data flows are described in [RFC 6471]: = client to/from registry, registry to local data repository and registr= y to registry, as shown here:



    *--------*   &n= bsp;           *------------*      =         *------------*
    |        | (1). Client   | =            | (3).Registry  |   &nbs= p;        |
    | Client | <-----------> | =  Registry  |<------------->|  Registry  |<= /div>
    |        = ;|   to Registry |            |  to= Registry  |            |
    *--------*       &= nbsp;       *------------*          = ;     *------------*
&nbs= p;                     &n= bsp;           /  \       &nbs= p;                  \
            &= nbsp;                    = /    \                 &n= bsp;        \
             = ;                   /   &= nbsp;  \                  = ;        \
&nbs= p;                     &n= bsp;        /        \    = ;                     &nb= sp;v
        &n= bsp;                     = /          \           &n= bsp;             ...
             = ;                /     &n= bsp;      \
  &= nbsp;                    =     / (2). Distrib \
&nb= sp;                     &= nbsp;    / Registry data  \
             = ;             /  to local data   \<= /font>
          =                V     &nbs= p;store         V
                    &n= bsp;   +----------+       +----------+
             = ;           |Local Data|       |Loc= al Data|
       = ;                 |Repository| &nbs= p;     |Repository|
 = ;                     &nb= sp; +----------+       +----------+

&n= bsp;                    T= hree Registry Provisioning Flows


=
This document addresses only the (1) Client to Registry asp= ect.  This document defines an abstract framework for the interaction = of registry clients with registries, referred to as the Session Peerin= g Provisioning Framework (SPPF).  This abstract framework is to be map= ped into specific protocol bindings in other documents, initially to SOAP i= n [draft-ietf-drinks-spp-soap].

The data provisioned for session establishment is typic= ally used by various downstream SIP signaling systems to route a call = to the next hop associated with the called domain.  These systems= typically use a local data store ("Local Data Repository") as their s= ource of session routing information.  More specifically, the SED= data is the set of parameters that the outgoing signaling path border= elements (SBEs) need to initiate the session.  See [RFC5486] for= more details.

A "terminating" SIP Service Provider (SSP) p= rovisions SED into the registry to be selectively shared with other SS= Ps. Subsequently, a registry may distribute the provisioned data into&= nbsp;local data repositories used for look-up queries (identifier -> URI= ) or for lookup and location resolution (identifier -> URI -> in= gress SBE of terminating SSP).  In some cases, the registry may&n= bsp;additionally offer a central query resolution service (not shown in&nbs= p;the above figure). Typically, this query resolution service will be somet= hing like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect s= erver.

The roles of  "client" and "server" are abstract and on= ly apply to the requesting and responding roles in given transactions and a= re not related in any way to the type of entity participating in a protocol= exchange.  For example, a registry might also include a "client"= when such a registry initiates a connection (for example, for data distrib= ution to an SSP).

... continue with existing text from "A key requirement= ..."
<ATT00001..c>



= --_000_A30A2B47A4384D298298B7F87F9CADA5xconnectnet_-- From dschwartz@xconnect.net Tue Apr 10 12:27:39 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A696D11E810A for ; Tue, 10 Apr 2012 12:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nudd-84V+CTL for ; Tue, 10 Apr 2012 12:27:38 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB78211E80DF for ; Tue, 10 Apr 2012 12:27:37 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Tue, 10 Apr 2012 22:27:36 +0300 From: David Schwartz To: Dean Willis Date: Tue, 10 Apr 2012 22:27:37 +0300 Thread-Topic: [drinks] Following up on SED data types from today's design call Thread-Index: Ac0XT/vnk97w2wz+T/aJPEcZM3W7Qw== Message-ID: <92EA54DE-2B73-481F-AAEA-811A0223CBAA@xconnect.net> References: <243F061D-CAD2-49DA-93A4-A44943AF6707@softarmor.com> <48B10C7B-57AD-47AF-93BE-AF667D926E0A@xconnect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_92EA54DE2B73481FAAEA811A0223CBAAxconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Following up on SED data types from today's design call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:27:39 -0000 --_000_92EA54DE2B73481FAAEA811A0223CBAAxconnectnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes - I know, Penn recommended a URN and I am inclined to agree as it is fa= r too tempting to make use of the host part of a URI for things other than = identification and a URN while more limiting makes the distinction clear. On Apr 10, 2012, at 7:56 PM, Dean Willis wrote: You may recall there's another IETF thread on defining SPID or something li= ke it. We're sortof stuck on a "standard" representation for SPID until tha= t completes, although one would hop it a UR-something. On Thu, Apr 5, 2012 at 4:11 AM, David Schwartz > wrote: Hi Dean I agree with point 1. Regarding point 2, the SPID is still the problem. You have shown two option= s, Next-hop URI and transformation - but how about the "non-next-hop" URI a= s in the case of a URI being used basically as an opaque string (e.g. SPID)= ? Does anyone remember why we went with a URI and not a URN for the SPID use = case? Wouldn't a URN solve the problem? i.e.. have 3 types... URI, URN and = transformation... :D On Apr 5, 2012, at 4:05 AM, Dean Willis wrote: > > David S. sent out an email before the call today that proposed an abstrac= ted restructuring of the Route Record into a SED Type, with subtypes Locati= on and Target. > > Discussion on today's call seemed to reveal that we might be able to addr= ess his concerns with something simpler. > > I think we've been getting tangled up between the two basic questions abo= ut SED data: > > 1) What is the data? > Is it a SIP URI? > An NS record? > A NAPTR record? > A routing number? > A SPID? > An XMPP URI? > A tel: URI? > An H.323 URI? > An arbitrary string? > A template to which we apply a regex transform using the > > 2) What are we supposed to DO with the data once, we have it in hand? > Route the request there? > Retarget the call to that destination? > Use the service indicated by the SED data to look up a next action? > Use the SED data as a key into some other routing database > > > I'd argue that most of the "What is it" problems become moot if we simple= say "It's a URI", because examination of a naked URI tells us a lot about = the encoded data. We know to use a SIP URI with SIP, an XMPP URI with XMPP,= and so on. For NSType and NAPTRType, we have RFC 4501 "Domain Name System = Uniform Resource Identifiers". We probably also need an optional regular ex= pression for further processing of the SED data. > > So if we answer #1 by saying "It's a URI, dude! And it might have a regex= with it!" we have answered half the question space. This might not cover S= PIDs (still a standards-undefined-thing) and telephone number ranges (which= are partially specified in RFC 3966). But it does cover the cases in draft= -ietf-drinks-spp-framework-01. > > As for question #2: > > David seems to think that there are are a couple of roles for SED data, m= ostly using RFC 5486 terms, and that we need to tell the recipient of the S= ED data how to use that data; that is, what the role of the data is. So far= , this makes sense to me. The next step is where it gets fuzzy.... > > We seem to have: > > LUF, which we query for a new target domain to which we should route the = request. I THINK David called this a TargetType in his morning email. > > LRF, which we query for a signaling-function to which we will send the a= ctual request. I THINK David called this a LocationType in his morning emai= l. > > SPID, which we somehow use magically as sort of a LUF for an LRF; in othe= r words, we use the SPID to find a LUF which will give us an LRF. > > RN, or routing number, which seems to work like a SPID but is itself a ph= one number. > > > I'm not sure this makes sense, either. Then again, the subtlety of LRF an= d LUF has always escaped me. A SIP proxy in domain X might route an INVITE,= or it might redirect it, and in either case the "target" might be in domai= ns X or Y, and if you send it a request, you have to be prepared for it to = do either. > > > I think instead we have two possible "types" of responses. > > 1) A next-hop URI. If it's the sort of URI that gets queried (NS), the us= er queries it. If it's the sort of URI that you send the request to and it = routes or redirects (SIP, XMPP), the user sends the request to it, and the = right thing happens. Given a URI, why does a user need to know whether it's= an LUF or an LRF? > > 2) A transformation. The user takes the response, applies it to the exist= ing data using a regex-replacement, and tries again. > > > In the framework, this "transformation" is muddled up in a combination of= the URIRteRecType (framework-01, bottom of page 33) and its pattern,= and the EgrRteType (framework-01, page 38). This confuses me beyond all co= mprehension. > > > Could we solve the whole can of worms by replacing "Egress Route" and "Ro= ute Record" with a "SED Record" containing the base type plus a URI plus a = regex? > > -- > Dean > > > > > > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks --_000_92EA54DE2B73481FAAEA811A0223CBAAxconnectnet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes - I know, Penn recomme= nded a URN and I am inclined to agree as it is far too tempting to make use= of the host part of a URI for things other than identification and a URN w= hile more limiting makes the distinction clear.


On Apr 10, 2012, at 7:56 PM, Dean Willis wrote:

You may recall there's an= other IETF thread on defining SPID or something like it. We're sortof stuck= on a "standard" representation for SPID until that completes, although one= would hop it a UR-something.

On Thu, Apr 5, 2012 at 4:11 AM, David Schwar= tz <dschwart= z@xconnect.net> wrote:
Hi Dean

I agree with point 1.

Regarding point 2, the SPID is still the problem. You have shown two option= s, Next-hop URI and transformation - but how about the "non-next-hop" URI a= s in the case of a URI being used basically as an opaque string (e.g. SPID)= ?

Does anyone remember why we went with a URI and not a URN for the SPID use = case? Wouldn't a URN solve the problem? i.e.. have 3 types... URI, URN and = transformation...

:D

On Apr 5, 2012, at 4:05 AM, Dean Willis wrote:

>
> David S. sent out an email before the call today that proposed an abst= racted restructuring of the Route Record into a SED Type, with subtypes Loc= ation and Target.
>
> Discussion on today's call seemed to reveal that we might be able to a= ddress his concerns with something simpler.
>
> I think we've been getting tangled up between the two basic questions = about SED data:
>
> 1) What is the data?
>       Is it a SIP URI?
>       An NS record?
>       A NAPTR record?
>       A routing number?
>       A SPID?
>       An XMPP URI?
>       A tel: URI?
>       An H.323 URI?
>       An arbitrary string?
>       A template to which we apply a regex transform us= ing the
>
> 2) What are we supposed to DO with the data once, we have it in hand?<= br> >       Route the request there?
>       Retarget the call to that destination?
>       Use the service indicated by the SED data to look= up a next action?
>       Use the SED data as a key into some other routing= database
>
>
> I'd argue that most of the "What is it" problems become moot if we sim= ple say "It's a URI", because examination of a naked URI tells us a lot abo= ut the encoded data. We know to use a SIP URI with SIP, an XMPP URI with XM= PP, and so on. For NSType and NAPTRType, we have RFC 4501 "Domain Name Syst= em Uniform Resource Identifiers". We probably also need an optional regular= expression for further processing of the SED data.
>
> So if we answer #1 by saying "It's a URI, dude! And it might have a re= gex with it!" we have answered half the question space. This might not cove= r SPIDs (still a standards-undefined-thing) and telephone number ranges (wh= ich are partially specified in RFC 3966). But it does cover the cases in dr= aft-ietf-drinks-spp-framework-01.
>
> As for question #2:
>
> David seems to think that there are are a couple of roles for SED data= , mostly using RFC 5486 terms, and that we need to tell the recipient of th= e SED data how to use that data; that is, what the role of the data is. So = far, this makes sense to me. The next step is where it gets fuzzy....
>
> We seem to have:
>
> LUF, which we query for a new target domain to which we should route t= he request.  I THINK David called this a TargetType in his morning ema= il.
>
> LRF, which we  query for a signaling-function to which we will se= nd the actual request. I THINK David called this a LocationType in his morn= ing email.
>
> SPID, which we somehow use magically as sort of a LUF for an LRF; in o= ther words, we use the SPID to find a LUF which will give us an LRF.
>
> RN, or routing number, which seems to work like a SPID but is itself a= phone number.
>
>
> I'm not sure this makes sense, either. Then again, the subtlety of LRF= and LUF has always escaped me. A SIP proxy in domain X might route an INVI= TE, or it might redirect it, and in either case the "target" might be in do= mains X or Y, and if you send it a request, you have to be prepared for it = to do either.
>
>
> I think instead we have two possible "types" of responses.
>
> 1) A next-hop URI. If it's the sort of URI that gets queried (NS), the= user queries it. If it's the sort of URI that you send the request to and = it routes or redirects (SIP, XMPP), the user sends the request to it, and t= he right thing happens. Given a URI, why does a user need to know whether i= t's an LUF or an LRF?
>
> 2) A transformation. The user takes the response, applies it to the ex= isting data using a regex-replacement, and tries again.
>
>
> In the framework, this "transformation" is muddled up in a combination= of the URIRteRecType (framework-01, bottom of page 33) and its <ere>= pattern, and the EgrRteType (framework-01, page 38). This confuses me beyo= nd all comprehension.
>
>
> Could we solve the whole can of worms by replacing "Egress Route" and = "Route Record" with a "SED Record" containing the base type plus a URI plus= a regex?
>
> --
> Dean
>
>
>
>
>
>
> _______________________________________________
> drinks mailing list
> drinks@ietf.org
> https://www.ietf.org/mailman/listinfo/drinks



= --_000_92EA54DE2B73481FAAEA811A0223CBAAxconnectnet_-- From dean.willis@softarmor.com Tue Apr 10 14:33:27 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D06C21F868A for ; Tue, 10 Apr 2012 14:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGrBtT2-FK3k for ; Tue, 10 Apr 2012 14:33:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3251D21F8663 for ; Tue, 10 Apr 2012 14:33:26 -0700 (PDT) Received: by ghbg16 with SMTP id g16so204456ghb.31 for ; Tue, 10 Apr 2012 14:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8y1lDK8fOkO4JY03AtJKBaBYDXpiMaIokqKl2HLOig=; b=GITOS1AD7aZ/vzfCMK4B/kdtO0eUVPda9yqkR6SJR6vGq5TZjn8pGQbxTYyWd4slpz bDHp0Qu70Kc31ZcSRrjIalCXIC5xa2kmUDYivUhv/fkUMzm9lc/+3crB0gGH1evwDrTy Z4LpJunaPPXw3K3/QZE5p2dRx84xcd2QMoiao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=y8y1lDK8fOkO4JY03AtJKBaBYDXpiMaIokqKl2HLOig=; b=nlULjLi2wqRkXbA035zf1MA7ECV3+uPbkvH0UaZWCJReCrjGA/6F+NjfW3E5vd/JSQ FjlzWjNr0Op+dT0JxGqJYO5N5kxP1fxNiNdsCJ2pbgM+ZnUFjiEZ/VMAeCO31z7Z1veK ECdetwlZpq1IN2g4aafHdcp+ikuo1FNNeb1042YC8t3BWJ2U/H2NmpgOp4y0k3cRk8D3 +Kr0WYwNpIOVLske3Fwm5QN89Mh33XnrPwZ1rjKyQibbIMitBa8U8emIejvbp0uYNzM7 mLBhpHPYGA3XR97IMDVvSN41Ub6ZT7nzYAZyLjDK275Zg9jErxjPNjz0ZTxvJFQX/eoQ bIzQ== MIME-Version: 1.0 Received: by 10.60.4.170 with SMTP id l10mr18276853oel.67.1334093605500; Tue, 10 Apr 2012 14:33:25 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Tue, 10 Apr 2012 14:33:25 -0700 (PDT) In-Reply-To: <92EA54DE-2B73-481F-AAEA-811A0223CBAA@xconnect.net> References: <243F061D-CAD2-49DA-93A4-A44943AF6707@softarmor.com> <48B10C7B-57AD-47AF-93BE-AF667D926E0A@xconnect.net> <92EA54DE-2B73-481F-AAEA-811A0223CBAA@xconnect.net> Date: Tue, 10 Apr 2012 16:33:25 -0500 Message-ID: From: Dean Willis To: David Schwartz Content-Type: multipart/alternative; boundary=e89a8fb1f86273f5ee04bd59dfac X-Gm-Message-State: ALoCoQkQscci9VVaKHhwv9O6LVIcyuZ2XIll17oeuSNvSgezlj5O07s+BPSKFlhaggJs+0aepHV8 Cc: "drinks@ietf.org" Subject: Re: [drinks] Following up on SED data types from today's design call X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:33:27 -0000 --e89a8fb1f86273f5ee04bd59dfac Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 2:27 PM, David Schwartz wrote: > Yes - I know, Penn recommended a URN and I am inclined to agree as it is > far too tempting to make use of the host part of a URI for things other > than identification and a URN while more limiting makes the distinction > clear. > > I just inquired with Richard, and he is still expecting an 8-digit numerical URN. -- Dean --e89a8fb1f86273f5ee04bd59dfac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 10, 2012 at 2:27 PM, David Schwa= rtz <dschwar= tz@xconnect.net> wrote:
Yes - I know, Penn recommended a URN an= d I am inclined to agree as it is far too tempting to make use of the host = part of a URI for things other than identification and a URN while more lim= iting makes the distinction clear.

=A0
I just inquired with Richard, and he is still expecting an 8-digit = numerical URN.

--
Dean
--e89a8fb1f86273f5ee04bd59dfac-- From dean.willis@softarmor.com Tue Apr 10 20:35:01 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEB011E80F6 for ; Tue, 10 Apr 2012 20:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoOIO05JPmhF for ; Tue, 10 Apr 2012 20:35:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA38B11E809B for ; Tue, 10 Apr 2012 20:35:00 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so751480obb.31 for ; Tue, 10 Apr 2012 20:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RvdV/fRBUXO0dAtxEqqYDulf36D7W2GApsx0jUuGx+c=; b=g7hrxWxNueb6S422YsdvUFrTLK99I2VWuKsL1u7peERlZXDaegR2NA7NLCreAhBGzc 02w/RP0/JvF1CuVIlT1+3qrk8bUV5/DPMSSs7oyfxr2d0fNT/FUWaxzL1h6eN4BddpSD K5vQsOaRQRVEp0AVOCd02PdPRBHfTN5qRi9I4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=RvdV/fRBUXO0dAtxEqqYDulf36D7W2GApsx0jUuGx+c=; b=bxVtvj71PlwKJBcTtednnt2Xg55R72yqTYDz2krDRWV3uaqKnj7d1HVqMCMbtoWWP1 TiqJP1x1luMB5vNGUaNYCIoHzagafBi30Hl4RVMd8E1Tlt5A+zaVnJzAxhIK4B5wXGxn C2yJFC2lOLVzmYdfqHMwt7HFrPn7tBPx8Z5RcrCMjbJLYycpprzj0GY6aXbhePzxvXKZ NUxuQCYf8TxNUwRrxDMdvdbzCCgW8bjK2/FsWRpDI7HX1N7WFz2ukEorsQBjTmsb9RP+ flin0g58dzPDqsZOEfzH0Px8aTCN94w2uMhkozj8CBIEWURcPat//X3hRXSu9juEA+4C NMSA== MIME-Version: 1.0 Received: by 10.182.119.6 with SMTP id kq6mr19602605obb.67.1334115300290; Tue, 10 Apr 2012 20:35:00 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Tue, 10 Apr 2012 20:35:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 22:35:00 -0500 Message-ID: From: Dean Willis To: David Schwartz , drinks@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ee23902fa904bd5eecbc X-Gm-Message-State: ALoCoQmgzrm38X2lTZM/FLRSkaq00evNDt1bkmnNSOUiSw103iCqoroVMHrDV4Hvfpm53N/BPM/d Subject: Re: [drinks] What do we mean by "peering"? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 03:35:02 -0000 --f46d0444ee23902fa904bd5eecbc Content-Type: text/plain; charset=ISO-8859-1 So what's the difference between what is returned by an LUF or an LRF? I think we can return several things from a query for a TN: A SIP URI that points ... somewhere. It might be to a terminal SIP UA, it might be to a gateway, it might be to a proxy, or it might point to a redirect server. We can't tell which of these it points to by inspection of the URI. Even if we knew which of these functions it points to, we still know little about the relationship between the TN we're querying and the thing that the SIP URI points to, other than that we can "get to" that telephone number by exercising the URI. A NAPTR record with sip+e2u tells us little more; it might have priority variables so that we can rank this information against other responses. But we still don't know if exercising the NAPTR's URI is going to get us directly to the termination, or to a transit point, or to another lookup function. If we return an NS record, we know we're getting another lookup function, so that's something. And we know we're going to query that NS, but we don't know what we're going to get back. If we return a SPID (whatever that might be), we know we have yet another model of indirection to go on: the next thing we do is look up routes for that SPID (presumably, NOT in this registry), then send the request along those routes, again not knowing what the result will be. I think you're saying that we need to add more context to the data in the registry, so that we know what the meaning of a particular "SED record" is, and how it should be used, and what we expect to gain from exercising that SED record. You've characterized SED records as either "targets" or "routes", but I still feel pretty vague about the differences between these two. -- Dean --f46d0444ee23902fa904bd5eecbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So what's the difference between what is returned by an LUF or= an LRF?

I think we can return several things from= a query for a TN:

A SIP URI that points ... somew= here. It might be to a terminal SIP UA, it might be to a gateway, it might = be to a proxy, or it might point to a redirect server. We can't tell wh= ich of these it points to by inspection of the URI. Even if we knew which o= f these functions it points to, we still know little about the relationship= between the TN we're querying and the thing that the SIP URI points to= , other than that we can "get to" that telephone number by exerci= sing the URI.

A NAPTR record with sip+e2u tells us little more; it mi= ght have priority variables so that we can rank this information against ot= her responses. But we still don't know if exercising the NAPTR's UR= I is going to get us directly to the termination, or to a transit point, or= to another lookup function.

If we return an NS record, we know we're getting an= other lookup function, so that's something. And we know we're going= to query that NS, but we don't know what we're going to get back.<= /div>

If we return a SPID (whatever that might be), we know w= e have yet another model of indirection to go on: the next thing we do is l= ook up routes for that SPID (presumably, NOT in this registry), then send t= he request along those routes, again not knowing what the result will be.= =A0

I think you're saying that we need to add more cont= ext to the data in the registry, so that we know what the meaning of a part= icular "SED record" is, and how it should be used, and what we ex= pect to gain from exercising that SED record. You've characterized SED = records as either "targets" or "routes", but I still fe= el pretty vague about the differences between these two.

--
Dean

--f46d0444ee23902fa904bd5eecbc-- From dean.willis@softarmor.com Wed Apr 11 07:37:49 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768221F85CE for ; Wed, 11 Apr 2012 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 254+SHLyyT1T for ; Wed, 11 Apr 2012 07:37:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8E21F85CD for ; Wed, 11 Apr 2012 07:37:47 -0700 (PDT) Received: by yhkk25 with SMTP id k25so524580yhk.31 for ; Wed, 11 Apr 2012 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=O6+1dH/gYEEcFr+6IdxwjsrYH7pz+YhBcz4axgKjZWg=; b=SQNgQnt4/Yz4mux/1vgXV3PBMyqOO5tU9oDLTiTXHrdxcHPjkJt7m44b9rdUGSwjt0 jwqRcmkB2HS1j6OdBc7lCeh5AE76J1m/N+X6CLgrnLGJ40Ou4Q8YSKBVLj3CAdzoLqkW 6+mlbUy3aeSBjkdF9rE4SP877vrzKgJMFoeJw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=O6+1dH/gYEEcFr+6IdxwjsrYH7pz+YhBcz4axgKjZWg=; b=KyjFBXDlDEi5gho7Dw5jrXeC+YomXqWljMJh0uxjiMBZGhOsRC46Dm+0VaYU9y/cO6 Ndfhk73K8NWsxk+vOZa+vHHF3DxOpwE9o5pUBYyUxIfwjjF9WW72pJRvYJrpRETxqNGN mxzve1HoCcTf7RHhKhO+/nOz0fvNP90LENVG5dzdo9TGj+HG1VSWn4e6juESQJwG4K9Q aGtMU6Uw23xkQ8PvNqQsTNmALPoWsQ6oRmLmA/ndg+Wfh79Cn2OH3plAjaC+zaTpU7c4 50e8X7uc05EGWKliVf5/3TaZ06I2FdlDPnk+VHdYKJUNANy+YeuU1WKIWK2BQn6x9AMB cY1Q== MIME-Version: 1.0 Received: by 10.60.4.170 with SMTP id l10mr22548125oel.67.1334155066964; Wed, 11 Apr 2012 07:37:46 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Wed, 11 Apr 2012 07:37:46 -0700 (PDT) Date: Wed, 11 Apr 2012 09:37:46 -0500 Message-ID: From: Dean Willis To: drinks@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb1f862d779d704bd682ed5 X-Gm-Message-State: ALoCoQnT+ZP8bvJNm9+gYGePM2slobxPPeyErxC8JyVhN1TR8jbsyvoMyBwMx/g8n7w9ctxzaU7O Subject: [drinks] Recap on Proposed change to Framework intro X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:37:49 -0000 --e89a8fb1f862d779d704bd682ed5 Content-Type: text/plain; charset=ISO-8859-1 Recapping from the discussion we had on the list. I believe the following might suffice for getting the concerns raised by David about the scope of "peering" into the document. I'm personally still vague on the difference between routing and targeting, but I don't think that matters much for this text. 1. Introduction Service providers and enterprises use registries to make session routing/targeting decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning framework for these registries. In other words, the goal is to allow users to put session establishment data (SED) into a registry, to share that SED selectively with other users of that registry, and to allow those other users to further select a subset of that SED for use in their own applications. The requirements and use cases driving this framework have been documented in [RFC 6461], and the reader is expected to be familiar with the terminology defined therein. The SED described in this framework is limited to simple routing/targeting data. Although the terms "peer" and "peering" are used, these refer only to the sharing of basic call routing/targeting information between users of the registry, and do not address the broad range of policy factors that might be used in a commercial peering "clearinghouse" operation. In short "peering organizations" are other users of the same registry, and "peers" are users of that registry to whom the offer of sharing specific SED has been extended, and who have accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from registry, registry to local data repository and registry to registry, as shown here: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This document defines an abstract framework for the interaction of registry clients with registries, referred to as the Session Peering Provisioning Framework (SPPF). This abstract framework is to be mapped into specific protocol bindings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain. These systems typically use a local data store ("Local Data Repository") as their source of session routing information. More specifically, the SED data is the set of parameters that the outgoing signaling path border elements (SBEs) need to initiate the session. See [RFC5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other SSPs. Subsequently, a registry may distribute the provisioned data into local data repositories used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI -> ingress SBE of terminating SSP). In some cases, the registry may additionally offer a central query resolution service (not shown in the above figure). Typically, this query resolution service will be something like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server. The roles of "client" and "server" are abstract and only apply to the requesting and responding roles in given transactions and are not related in any way to the type of entity participating in a protocol exchange. For example, a registry might also include a "client" when such a registry initiates a connection (for example, for data distribution to an SSP). ... continue with existing text from "A key requirement..." --e89a8fb1f862d779d704bd682ed5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Recapping from the discussi= on we had on the list. I believe the following might suffice for getting th= e concerns raised by David about the scope of "peering" into the = document.

I'm personally still vague o= n the difference between routing and targeting, but I don't think that = matters much for this text.


1. =A0Introduction

Service p= roviders and enterprises use registries to make session routing/targeting d= ecisions for Voice over IP, SMS and MMS traffic exchanges. This document is= narrowly focused on the provisioning framework for these registries. =A0In= other words, the goal is to allow users to put session establishment data = (SED) into a registry, to share that SED selectively with other users of th= at registry, and to allow those other users to further select a subset of t= hat SED for use in their own applications. =A0The requirements and use case= s driving this framework have been documented in [RFC 6461], and the reader= is expected to be familiar with the terminology defined therein.

= The SED described in this f= ramework is limited to simple routing/targeting data. Although the terms &q= uot;peer" and "peering" are used, these refer only to the sh= aring of basic call routing/targeting information between users of the regi= stry, and do not address the broad range of policy factors that might be us= ed in a commercial peering "clearinghouse" operation. In short &q= uot;peering organizations" are other users of the same registry, and &= quot;peers" are users of that registry to whom the offer of sharing sp= ecific SED has been extended, and who have accepted that offer.

= Three types of data flows a= re described in [RFC 6471]: client to/from registry, registry to local data= repository and registry to registry, as shown here:

=

=A0 =A0 *--------* =A0 =A0 =A0 =A0 = =A0 =A0 =A0 *------------* =A0 =A0 =A0 =A0 =A0 =A0 =A0 *------------*
=A0 =A0 | =A0 =A0 =A0 = =A0| (1). Client =A0 | =A0 =A0 =A0 =A0 =A0 =A0| (3).Registry =A0| =A0 =A0 = =A0 =A0 =A0 =A0|
=A0 =A0 | Client | <-----------> | =A0Registry =A0|<-------= ------>| =A0Registry =A0|
=A0 =A0 | =A0 =A0 =A0 = =A0| =A0 to Registry | =A0 =A0 =A0 =A0 =A0 =A0| =A0to Registry =A0| =A0 =A0= =A0 =A0 =A0 =A0|
=A0 =A0 *--------* =A0 =A0 =A0 =A0 =A0 =A0 =A0 *------------* =A0 = =A0 =A0 =A0 =A0 =A0 =A0 *------------*
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0\ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0/ =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0\
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0\ =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0v
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0\ =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / (2). Distrib \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0/ Registry data =A0\
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 / =A0to local data =A0 \
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0V =A0 =A0 =A0store =A0 =A0 =A0 =A0 V
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 +----------+ =A0 =A0 =A0 =A0 +----------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |Local Data| =A0 =A0 =A0 =A0 |Local Data|
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |Repository| =A0 =A0 =A0 =A0 |Repository|
<= div>=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 +----------+ =A0 =A0 =A0 =A0 +----------+

= =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0Three Registry Provisioning Flows


This document = addresses only the (1) Client to Registry aspect. =A0This document defines = an abstract framework for the interaction of registry clients with registri= es, referred to as the Session Peering Provisioning Framework (SPPF). =A0Th= is abstract framework is to be mapped into specific protocol bindings in ot= her documents, initially to SOAP in [draft-ietf-drinks-spp-soap].

= The data provisioned for se= ssion establishment is typically used by various downstream SIP signaling s= ystems to route a call to the next hop associated with the called domain. = =A0These systems typically use a local data store ("Local Data Reposit= ory") as their source of session routing information. =A0More specific= ally, the SED data is the set of parameters that the outgoing signaling pat= h border elements (SBEs) need to initiate the session. =A0See [RFC5486] for= more details.

= A "terminating" S= IP Service Provider (SSP) provisions SED into the registry to be selectivel= y shared with other SSPs. Subsequently, a registry may distribute the provi= sioned data into local data repositories used for look-up queries (identifi= er -> URI) or for lookup and location resolution (identifier -> URI -= > ingress SBE of terminating SSP). =A0In some cases, the registry may ad= ditionally offer a central query resolution service (not shown in the above= figure). Typically, this query resolution service will be something like a= n ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server.

= The roles of =A0"clien= t" and "server" are abstract and only apply to the requestin= g and responding roles in given transactions and are not related in any way= to the type of entity participating in a protocol exchange. =A0For example= , a registry might also include a "client" when such a registry i= nitiates a connection (for example, for data distribution to an SSP).

= ... continue with existing = text from "A key requirement..."
--e89a8fb1f862d779d704bd682ed5-- From richard@shockey.us Wed Apr 11 10:10:15 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F2111E808D for ; Wed, 11 Apr 2012 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.195 X-Spam-Level: X-Spam-Status: No, score=-99.195 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db1Kt3RJ-Ms9 for ; Wed, 11 Apr 2012 10:10:13 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id E34F421F84D0 for ; Wed, 11 Apr 2012 10:10:12 -0700 (PDT) Received: (qmail 4790 invoked by uid 0); 11 Apr 2012 17:10:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 11 Apr 2012 17:10:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=pWp0crvL7gTc46xsRkTQNVk7HNWctSqQxY9aqK5+Q+s=; b=M6c6e85RUT4M9ABwEgcmYf1QZAfWGJ7ZAlK9eFjL1NGumldhmGsFDKMb0SrhOl95a5DSJa63L4Z5rLymd6qL87uAnqcd6vCtTIUGRysp0RBHTkMTIwNSGzgI58g+O7Ka; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SI13Z-0004hH-Kf; Wed, 11 Apr 2012 11:10:10 -0600 From: "Richard Shockey" To: "'Dean Willis'" , References: In-Reply-To: Date: Wed, 11 Apr 2012 13:10:06 -0400 Message-ID: <010f01cd1805$f22b75d0$d6826170$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0110_01CD17E4.6B19D5D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0XlBUWWWd2pJUHQJGk55T98W6NlwAb7CUg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: Re: [drinks] What do we mean by "peering"? X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:10:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0110_01CD17E4.6B19D5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If we return an NS record, we know we're getting another lookup function, so that's something. And we know we're going to query that NS, but we don't know what we're going to get back. If we return a SPID (whatever that might be), we know we have yet another model of indirection to go on: the next thing we do is look up routes for that SPID (presumably, NOT in this registry), then send the request along those routes, again not knowing what the result will be. [RS> ] IN the context of a SED a SPID [Service Provider Identification Code] is the identifier for Service Provider of Record for the target. In NPAC terms its "A NPAC SPID is the OCN of a service provider. This is a unique four character alphanumeric value. Shown for the owner of each ported number record in the NPAC. A secondary SPID, called the "alternative SPID," also may be associated with a ported number record. This alternative SPID value may not be an OCN, but instead may be drawn from the series X000 to X999." As most of us know by this time the secondary look up is generally internal to the originating network and may include route data determined by bilateral agreement. I think we all generally know what is going on here. Since some folks did not want to expose their end point target ( the SBC ..duh) topology in a database, he first order resolution was simply to find who "owns the number" then check my excel spreadsheet for the target URI's for a particular portability corrected NPA NXX etc. Make a trunk group decision ..youre done. Bypass Intercarrier Compensation collect 400 Million dollars Pass GO become Vice President of some service provider. I think you're saying that we need to add more context to the data in the registry, so that we know what the meaning of a particular "SED record" is, and how it should be used, and what we expect to gain from exercising that SED record. You've characterized SED records as either "targets" or "routes", but I still feel pretty vague about the differences between these two. [RS> ] Yep I get this ..it really is the target (aka SBC ) and then the route ( trunk port at Equinix, 80 Hudson, 1 Wiltshire ) since the route may be determined by other factors and use various QoS mechanisms a well. This is not the DNS and this is definitely NOT a best efforts service. -- Dean ------=_NextPart_000_0110_01CD17E4.6B19D5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

If we return an NS record, we know we're getting = another lookup function, so that's something. And we know we're going to = query that NS, but we don't know what we're going to get = back.

 

If we return a SPID (whatever that might be), we know = we have yet another model of indirection to go on: the next thing we do = is look up routes for that SPID (presumably, NOT in this registry), then = send the request along those routes, again not knowing what the result = will be. 

 

[RS> ] IN the context of a SED a SPID [Service Provider = Identification Code] is the identifier for Service Provider of Record = for the target.

 

In NPAC terms its “A NPAC SPID is the OCN of a = service provider. This is a unique four character alphanumeric value. = Shown for the owner of each ported number record in the NPAC. A = secondary SPID, called the “alternative SPID,” also may be = associated with a ported number record. This alternative SPID value may = not be an OCN, but instead may be drawn from the series X000 to = X999.”

 

As most of us know by this time the secondary look up = is generally internal to the originating network and may include route = data determined by bilateral agreement. I think we all generally know = what is going on here.  Since some folks did not want to expose = their end point target ( the SBC ..duh) topology in a database, he first = order resolution was simply to find who “owns the number” = then check my excel spreadsheet for the target URI’s for a = particular portability corrected NPA NXX etc.  Make a trunk group = decision ..youre done. Bypass Intercarrier Compensation collect 400 = Million dollars Pass GO become Vice President of some service provider. =

 

 

I = think you're saying that we need to add more context to the data in the = registry, so that we know what the meaning of a particular "SED = record" is, and how it should be used, and what we expect to gain = from exercising that SED record. You've characterized SED records as = either "targets" or "routes", but I still feel = pretty vague about the differences between these two.

[RS> ] Yep I get this ..it really is the target (aka SBC ) and = then the route ( trunk port at Equinix, 80 Hudson, 1 Wiltshire  ) = since the route may be determined by other factors and use various QoS = mechanisms a well.  This is not the DNS and this is definitely NOT = a  best efforts service.

 

--
Dean

 

------=_NextPart_000_0110_01CD17E4.6B19D5D0-- From kcartwright@tnsi.com Wed Apr 11 12:58:24 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3321F84CE for ; Wed, 11 Apr 2012 12:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiCiimcxY9eR for ; Wed, 11 Apr 2012 12:58:20 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4FF21F84CD for ; Wed, 11 Apr 2012 12:58:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EABXhhU+sEQfn/2dsb2JhbAA6CoJGuBeCCQEBBScGXAIBCBEEAQEhBwcyFAkIAQEEARIIwyOLIQQFhWhjBKklgTgI X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208,217";a="1113963" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 11 Apr 2012 20:58:02 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 11 Apr 2012 15:58:02 -0400 From: "Cartwright, Ken" To: Dean Willis , "drinks@ietf.org" Date: Wed, 11 Apr 2012 15:58:05 -0400 Thread-Topic: [drinks] Recap on Proposed change to Framework intro Thread-Index: Ac0X8K5Wf0LFd9tSTJec44ZiRgxGWwAKc8NA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC303153D9853TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Recap on Proposed change to Framework intro X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:58:24 -0000 --_000_B4254E341B54864B92D28BC2138A9DC303153D9853TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dean, 1) Can you please identify the diffs. Thanks. 2) From a general perspective, the framework supports what it supports. So= adding in text to somehow further bound or expand on that seems un-necessa= ry. It is certainly true that neither the Use Case document nor the result= ing framework or protocol documents have attempted to include or support al= l types of use cases that can be involved on route generation and selection= (e.g. Time Based Route Selection, Dial Plans, etc, etc). Early on, the sc= ope was deemed to be more limited than that, because that broader scope wou= ld have been too large, and moving, and varying. If we wish to expand the = scope covered by the Use Case document and/or the framework then that is a = different matter. But adding in vague language here that seems to sort-of = apologize for the scope seems a little odd to me. 3) Introduction of the word "targeting" cries out for a definition. Afaik,= this is a term that has not been defined here or in another document. But= if that definition does exist then can you point us at it. Thanks. I don= 't think we can get away with just "slipping it in" here. It's just too no= ticeable when used in this context. 4) The phrase "commercial peering "clearinghouse" operation" could probably= be either removed or altered. For example, whether the implementing regis= try is "commercial" or not is not relevant, and whether the implementing re= gistry considers itself a "clearinghouse" is not relevant. Thanks for considering these points. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Wednesday, April 11, 2012 10:38 AM To: drinks@ietf.org Subject: [drinks] Recap on Proposed change to Framework intro Recapping from the discussion we had on the list. I believe the following m= ight suffice for getting the concerns raised by David about the scope of "p= eering" into the document. I'm personally still vague on the difference between routing and targeting,= but I don't think that matters much for this text. 1. Introduction Service providers and enterprises use registries to make session routing/ta= rgeting decisions for Voice over IP, SMS and MMS traffic exchanges. This do= cument is narrowly focused on the provisioning framework for these registri= es. In other words, the goal is to allow users to put session establishmen= t data (SED) into a registry, to share that SED selectively with other user= s of that registry, and to allow those other users to further select a subs= et of that SED for use in their own applications. The requirements and use= cases driving this framework have been documented in [RFC 6461], and the r= eader is expected to be familiar with the terminology defined therein. The SED described in this framework is limited to simple routing/targeting = data. Although the terms "peer" and "peering" are used, these refer only to= the sharing of basic call routing/targeting information between users of t= he registry, and do not address the broad range of policy factors that migh= t be used in a commercial peering "clearinghouse" operation. In short "peer= ing organizations" are other users of the same registry, and "peers" are us= ers of that registry to whom the offer of sharing specific SED has been ext= ended, and who have accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from regis= try, registry to local data repository and registry to registry, as shown h= ere: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This docum= ent defines an abstract framework for the interaction of registry clients w= ith registries, referred to as the Session Peering Provisioning Framework (= SPPF). This abstract framework is to be mapped into specific protocol bind= ings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by various= downstream SIP signaling systems to route a call to the next hop associate= d with the called domain. These systems typically use a local data store (= "Local Data Repository") as their source of session routing information. M= ore specifically, the SED data is the set of parameters that the outgoing s= ignaling path border elements (SBEs) need to initiate the session. See [RF= C5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the registry= to be selectively shared with other SSPs. Subsequently, a registry may dis= tribute the provisioned data into local data repositories used for look-up = queries (identifier -> URI) or for lookup and location resolution (identifi= er -> URI -> ingress SBE of terminating SSP). In some cases, the registry = may additionally offer a central query resolution service (not shown in the= above figure). Typically, this query resolution service will be something = like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server= . The roles of "client" and "server" are abstract and only apply to the requ= esting and responding roles in given transactions and are not related in an= y way to the type of entity participating in a protocol exchange. For exam= ple, a registry might also include a "client" when such a registry initiate= s a connection (for example, for data distribution to an SSP). ... continue with existing text from "A key requirement..." ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC303153D9853TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dean,

 

1) Can you please identify the diffs. =  Thanks.

2) From a general perspective, the fra= mework supports what it supports.  So adding in text to somehow furthe= r bound or expand on that seems un-necessary.  It is certainly true that neither the Use Case d= ocument nor the resulting framework or protocol documents have attempted to= include or support all types of use cases that can be involved on route ge= neration and selection (e.g. Time Based Route Selection, Dial Plans, etc, etc).  Early on, the scope was deem= ed to be more limited than that, because that broader scope would have been= too large, and moving, and varying.  If we wish to expand the scope c= overed by the Use Case document and/or the framework then that is a different matter.  But adding in vague langu= age here that seems to sort-of apologize for the scope seems a little odd t= o me.

3) Introduction of the word “tar= geting” cries out for a definition.  Afaik, this is a term that = has not been defined here or in another document.  But if that definition does exist then can you point us at= it.  Thanks.  I don’t think we can get away with just R= 20;slipping it in” here.  It’s just too noticeable when us= ed in this context.

4) The phrase “commercial peerin= g “clearinghouse” operation” could probably be either rem= oved or altered.  For example, whether the implementing registry is “commercial” or not is not relevant, and whether t= he implementing registry considers itself a “clearinghouse” is = not relevant.  

 

Thanks for considering these points.

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Wednesday, April 11, 2= 012 10:38 AM
To: drinks@ietf.org
Subject: [drinks] Recap on P= roposed change to Framework intro

 

Recapping from the discussion we had on the list. I = believe the following might suffice for getting the concerns raised by Davi= d about the scope of "peering" into the document.

 

I'm personally still vague on the difference between= routing and targeting, but I don't think that matters much for this text.<= /span>

 

 

1.  Introduction

 

Service providers and enterprises use registries to = make session routing/targeting decisions for Voice over IP, SMS and MMS tra= ffic exchanges. This document is narrowly focused on the provisioning framework for these registries. &n= bsp;In other words, the goal is to allow users to put session establishment= data (SED) into a registry, to share that SED selectively with other users= of that registry, and to allow those other users to further select a subset of that SED for use in their own ap= plications.  The requirements and use cases driving this framework hav= e been documented in [RFC 6461], and the reader is expected to be familiar = with the terminology defined therein.

 

The SED described in this framework is limited to si= mple routing/targeting data. Although the terms "peer" and "= peering" are used, these refer only to the sharing of basic call routing/targeting information between users of t= he registry, and do not address the broad range of policy factors that migh= t be used in a commercial peering "clearinghouse" operation. In s= hort "peering organizations" are other users of the same registry, and "peers" are users of that registry to = whom the offer of sharing specific SED has been extended, and who have acce= pted that offer.

 

Three types of data flows are described in [RFC 6471= ]: client to/from registry, registry to local data repository and registry = to registry, as shown here:

 

 

 

    *--------*        =       *------------*           &nb= sp;   *------------*

    |        | (1). Cl= ient   |            | (3).Registry  = ;|            |

    | Client | <-----------> |  = ;Registry  |<------------->|  Registry  |

    |        |   = to Registry |            |  to Registry =  |            |=

    *--------*        =       *------------*           &nb= sp;   *------------*

              &nb= sp;                   /  = \                     &nb= sp;    \

              &nb= sp;                  /   =  \                   &nbs= p;      \

              &nb= sp;                 /    =  \                   &nb= sp;      \

              &nb= sp;                /     =    \                 &nbs= p;        v

              &nb= sp;               /      =    \                 &nb= sp;       ...

              &nb= sp;              /       =      \

              &nb= sp;             / (2). Distrib \

              &nb= sp;            / Registry data  \=

              &nb= sp;           /  to local data   \

              &nb= sp;          V      store   &n= bsp;     V

              &nb= sp;     +----------+         +---= -------+

              &nb= sp;     |Local Data|         |Local Data|

              &nb= sp;     |Repository|         |Repository|

              &nb= sp;     +----------+         +---= -------+

 

              &nb= sp;      Three Registry Provisioning Flows

 

 

This document addresses only the (1) Client to Regis= try aspect.  This document defines an abstract framework for the inter= action of registry clients with registries, referred to as the Session Peering Provisioning Framework= (SPPF).  This abstract framework is to be mapped into specific protoc= ol bindings in other documents, initially to SOAP in [draft-ietf-drinks-spp= -soap].

 

The data provisioned for session establishment is ty= pically used by various downstream SIP signaling systems to route a call to= the next hop associated with the called domain.  These systems typically use a local data sto= re ("Local Data Repository") as their source of session routing i= nformation.  More specifically, the SED data is the set of parameters = that the outgoing signaling path border elements (SBEs) need to initiate the session.  See [RFC5486] for more details.=

 

A "terminating" SIP Service Provider (SSP)= provisions SED into the registry to be selectively shared with other SSPs.= Subsequently, a registry may distribute the provisioned data into local data repositories used for look-up queries= (identifier -> URI) or for lookup and location resolution (identifier -= > URI -> ingress SBE of terminating SSP).  In some cases, the re= gistry may additionally offer a central query resolution service (not shown in the above figure). Typically, this query = resolution service will be something like an ENUM [RFC 3761] server or a SI= P [RFC 3261] proxy or redirect server.

 

The roles of  "client" and "serv= er" are abstract and only apply to the requesting and responding roles= in given transactions and are not related in any way to the type of entity participating in a protocol exchange.  For = example, a registry might also include a "client" when such a reg= istry initiates a connection (for example, for data distribution to an SSP)= .

 

... continue with existing text from "A key req= uirement..."


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC303153D9853TNSMAILNAwin2_-- From dean.willis@softarmor.com Wed Apr 11 19:24:42 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA011E80E3 for ; Wed, 11 Apr 2012 19:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT+m58fzmAu6 for ; Wed, 11 Apr 2012 19:24:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B70C11E80BF for ; Wed, 11 Apr 2012 19:24:36 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2346956obb.31 for ; Wed, 11 Apr 2012 19:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=bTKxrkp1b8z5aPfa/ot+clh0ISE176caecf/6NrJSNM=; b=EJfYOI6In19o+jEseB1JW+aIj82MjEfdp6ebxa4dwNLUIwnQB31BRn59moLk4oopZj lzFTQSnUEn6u8vETEI/kUNsmdljMpq/rRmKuG5DNxN4FV0qvF0QzsGUVwKXKXeSLkRvv t8z3rxWIZqDe5Hcei9ZCc8FZ2UM9zQkK4cTEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=bTKxrkp1b8z5aPfa/ot+clh0ISE176caecf/6NrJSNM=; b=QelmBkbW/3TQuZBpwIUV6qpaawk6xRtUzZY2BSX+wbwpG20k+47iAvQPm5zR1zMPa+ qx0xUHLo/dkwV8nKqaC0cuaULlh9SFzbog4B1UklI8sxRGOeuhWlMS0pTlZDYwfb9jex eI9m8Afaz72x0U0dzat4j+AXQOsIQBgOyiUdaa+PJiMLuk2w5NHjccOZ/P7PWQG97Co+ c7r85VzEvzsqX1xuCEKnzLOpYn5QqHfDXajkSbpfYFvaEQ4ZwQjy15D1bdFjccBlphPb nDnuDqNL6Rcx0WvkchdrGO1qfl82VGrgFnL/c3TUBw/HGQdZYQHhDvk7lllBm1JTaI+P PQRw== MIME-Version: 1.0 Received: by 10.60.28.137 with SMTP id b9mr759630oeh.57.1334197476395; Wed, 11 Apr 2012 19:24:36 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Wed, 11 Apr 2012 19:24:36 -0700 (PDT) Date: Wed, 11 Apr 2012 21:24:36 -0500 Message-ID: From: Dean Willis To: drinks@ietf.org, ewillis@ieee.org Content-Type: multipart/alternative; boundary=e89a8ff1c4aea4092e04bd720e0e X-Gm-Message-State: ALoCoQk8Tq3z67ooUHPOF2i6Y3fkJ52SiVP3y1BV9EiWMA7M3vELcfNovl2csEWQg5g5IianaIy9 Subject: [drinks] Diffs on Introduction as requested by Ken X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 02:24:42 -0000 --e89a8ff1c4aea4092e04bd720e0e Content-Type: text/plain; charset=ISO-8859-1 I hope this works. It probably won't; IETF mail server seems to hate MHTML. 11 1. Introduction22 3- Service providers and enterprises use4- registries to make session routing/targeting 3+ Service providers and enterprises use 4+ registries to make session routing 55 decisions for Voice over IP, SMS and MMS 66 traffic exchanges. This document is narrowly 77 focused on the provisioning framework for 8- these registries. In other words, the goal9- is to allow users to put session 10- establishment data (SED) into a registry, to 11- share that SED selectively with other users 12- of that registry, and to allow those other 13- users to further select a subset of that SED 14- for use in their own applications. The 15- requirements and use cases driving this 16- framework have been documented in [RFC 6461], 17- and the reader is expected to be familiar 18- with the terminology defined therein.19- 20- 21- The SED described in this framework is 22- limited to simple routing/targeting data. 23- Although the terms "peer" and "peering" are 24- used, these refer only to the sharing of 25- basic call routing/targeting information 26- between users of the registry, and do not 27- address the broad range of policy factors 28- that might be used in a commercial peering 29- "clearinghouse" operation. In short "peering 30- organizations" are other users of the same 31- registry, and "peers" are users of that 32- registry to whom the offer of sharing 33- specific SED has been extended, and who have 34- accepted that offer.35- 8+ these registries. This framework prescribes 9+ a way or an entity to provision session-10+ related data into a registry. The data 11+ being provisioned can be optionally shared 12+ with other participating peering entities. 13+ The requirements and use cases driving this 14+ framework have been documented in [RFC6461]. 15+ The reader is expected to be familiar with 16+ the terminology defined in the previously 17+ mentioned document.3618 37- Three types of data flows are described in 38- [RFC 6471]: client to/from registry, registry 39- to local data repository and registry to 40- registry, as shown here:4119 20+ Three types of provisioning flows have been 21+ described in the use case document: client 22+ to registry provisioning, registry to local 23+ data repository and registry to registry. 24+ This document addresses client to registry 25+ aspect to fulfill the need to provision 26+ Session Establishment Data (SED). The 27+ framework that supports flow of messages to 28+ facilitate client to registry provisioning 29+ is referred to as Session Peering 30+ Provisioning Framework (SPPF).4231 32+ Please note that the role of the "client" 33+ and the "server" only applies to the 34+ connection, and those roles are not related 35+ in any way to the type of entity that 36+ participates in a protocol exchange. For 37+ example, a registry might also include a 38+ "client" when such a registry initiates a 39+ connection (for example, for data 40+ distribution to SSP).4341 4442 4543 *--------* *------------* *------------*4644 | | (1). Client | | (3).Registry | |47- | Client | <-----------> | Registry |<------------->| Registry |45+ | Client | ------------> | Registry |<------------->| Registry |4846 | | to Registry | | to Registry | |4947 *--------* *------------* *------------*5048 / \ \51 49 / \ \5250 / \ \5351 / \ v5452 / \ ...5553 / \5654 / (2). Distrib \5755 / Registry data \5856 / to local data \5957 V store V60- +----------+ +----------+61- |Local Data| |Local Data|62- |Repository| |Repository|63- +----------+ +----------+58+ +----------+ +----------+59+ |Local Data| |Local Data|60+ |Repository| |Repository|61+ +----------+ +----------+6462 6563 Three Registry Provisioning Flows66- 67- 68- This document addresses only the (1) Client69- to Registry aspect. This document defines an 70- abstract framework for the interaction of 71- registry clients with registries, referred to 72- as the Session Peering Provisioning Framework 73- (SPPF). This abstract framework is to be 74- mapped into specific protocol bindings in 75- other documents, initially to SOAP in 76- [draft-ietf-drinks-spp-soap].7764 65+ Figure 17866 7967 The data provisioned for session 8068 establishment is typically used by various 8169downstream SIP signaling systems to route a 8270 call to the next hop associated with the 83- called domain. These systems typically use a 84- local data store ("Local Data Repository") as 85- their source of session routing information. 86- More specifically, the SED data is the set of 87- parameters that the outgoing signaling path 88- border elements (SBEs) need to initiate the 89- session. See [RFC5486] for more details.90- 71+ called domain. These systems typically use 72+ a local data store ("Local Data Repository") 73+ as their source of session routing 74+ information. More specifically, the SED data 75+ is the set of parameters that the outgoing 76+ signaling path border elements (SBEs) 77+ need to initiate the session. See [RFC5486] 78+ for more details.9179 9280A "terminating" SIP Service Provider (SSP) 9381 provisions SED into the registry to be 94- selectively shared with other SSPs. 82+ selectively shared with other peer SSPs. 9583 Subsequently, a registry may distribute the 96- provisioned data into local data repositories 97- used for look-up queries (identifier -> URI) 98- or for lookup and location resolution 99- (identifier -> URI -> ingress SBE of 100- terminating SSP). In some cases, the 101- registry may additionally offer a central 102- query resolution service (not shown in the 103- above figure). Typically, this query 104- resolution service will be something like an 105- ENUM [RFC 3761] server or a SIP [RFC 3261] 106- proxy or redirect server.107- 84+ provisioned data into local data 85+ repositories used for look-up queries 86+ (identifier -> URI)or for lookup and 87+ location resolution (identifier -> URI -> 88+ ingress SBE of terminating SSP). In some 89+ cases, the registry may additionally offer a 90+ central query resolution service (not shown 91+ in the above figure).10892 109- The roles of "client" and "server" are 110- abstract and only apply to the requesting and 111- responding roles in given transactions and 112- are not related in any way to the type of 113- entity participating in a protocol exchange. 114- For example, a registry might also include a 115- "client" when such a registry initiates a 116- connection (for example, for data 117- distribution to an SSP). --e89a8ff1c4aea4092e04bd720e0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I hope this works. It probably won't; IETF mail server seems to ha= te MHTML.

<= /tr> <= /tr> <= /tr> <= tr class=3D"del" style=3D"font-size:1em;background-image:initial;background= -color:rgb(255,221,221)"> <= tr class=3D"del" style=3D"font-size:1em;background-image:initial;background= -color:rgb(255,221,221)"> <= /tr> <= /tr> <= /tr> <= /tr> <= /tr> <= /tr> <= /tr> <= tr class=3D"add" style=3D"font-size:1em;background-image:initial;background= -color:rgb(221,255,221)"> <= /tr> <= /tr> <= /tr> <= /tr> <= tr class=3D"add" style=3D"font-size:1em;background-image:initial;background= -color:rgb(221,255,221)"> <= /tr>
1 1 1. Introduction
2 2
3 - Service providers and enterprises use
4 - registries to make session routing/targeting
3+ Service providers and enterprises use
4+ registries to make session routing
5 5 decisions for Voice over IP, SMS and MMS
6 6 traffic exchanges. This document is narrowly
7 7 focused on the provisioning framework for
8 - these registries. In other words, the goal
9 - is to allow users to put session
10 - establishment data (SED) into a registry, to
11 - share that SED selectively with other users
12 - of that registry, and to allow those other
13 - users to further select a subset of that SED
14 - for use in their own applications. The
15 - requirements and use cases driving this
16 - framework have been documented in [RFC 6461],
17 - and the reader is expected to be familiar
18 - with the terminology defined therein.
19 -
20 -
21 - The SED described in this framework is
22 - limited to simple routing/targeting data.
23 - Although the terms "peer" and "peeri= ng" are
24 - used, these refer only to the sharing of
25 - basic call routing/targeting information
26 - between users of the registry, and do not
27 - address the broad range of policy factors
28 - that might be used in a commercial peering
29 - "clearinghouse" operation. In short "= ;peering
30 - organizations" are other users of the same
31 - registry, and "peers" are users of that <= /td>
32 - registry to whom the offer of sharing
33 - specific SED has been extended, and who have
34 - accepted that offer.
35 -
8+ these registries. This framework prescribes
9+ a way or an entity to provision session-
10+ related data into a registry. The data
11+ being provisioned can be optionally shared
12+ with other participating peering entities.
13+ The requirements and use cases driving this
14+ framework have been documented in [RFC6461].
15+ The reader is expected to be familiar with
16+ the terminology defined in the previously
17+ mentioned document.
36 18
37 - Three types of data flows are described in
38 - [RFC 6471]: client to/from registry, registry
39 - to local data repository and registry to
40 - registry, as shown here:
41 19
20+ Three types of provisioning flows have been
21+ described in the use case document: client
22+ to registry provisioning, registry to local
23+ data repository and registry to registry.
24+ This document addresses client to registry
25+ aspect to fulfill the need to provision
26+ Session Establishment Data (SED). The
27+ framework that supports flow of messages to
28+ facilitate client to registry provisioning
29+ is referred to as Session Peering
30+ Provisioning Framework (SPPF).
42 31
32+ Please note that the role of the "client&quo= t;
33+ and the "server" only applies to the
34+ connection, and those roles are not related
35+ in any way to the type of entity that
36+ participates in a protocol exchange. For
37+ example, a registry might also include a
38+ "client" when such a registry initiates= a
39+ connection (for example, for data
40+ distribution to SSP).
43 41
44 42
45 43 *--------* *------------* = *------------*
46 44 | | (1). Client | | (3).R= egistry | |
47 - | Client | <-----------> | Registry |&l= t;------------->| Registry |
45+ | Client | ------------> | Registry |<= ;------------->| Registry |
48 46 | | to Registry | | to R= egistry | |
49 47 *--------* *------------* = *------------*
50 48 / \ = \
51 49 / \ = \
52 50 / \ = \
53 51 / \ = v
54 52 / \ = ...
55 53 / \
56 54 / (2). Distrib \
57 55 / Registry data \
58 56 / to local data \
59 57 V store V
60 - +----------+ +---------= -+
61 - |Local Data| |Local Dat= a|
62 - |Repository| |Repositor= y|
63 - +----------+ +---------= -+
58+ +----------+ +-----= -----+
59+ |Local Data| |Local= Data|
60+ |Repository| |Repos= itory|
61+ +----------+ +-----= -----+
64 62
65 63 Three Registry Provisioning = Flows
66 -
67 -
68 - This document addresses only the (1) Client
69 - to Registry aspect. This document defines an
70 - abstract framework for the interaction of
71 - registry clients with registries, referred to
72 - as the Session Peering Provisioning Framework
73 - (SPPF). This abstract framework is to be
74 - mapped into specific protocol bindings in
75 - other documents, initially to SOAP in
76 - [draft-ietf-drinks-spp-soap].
77 64
65+ Figure 1
78 66
79 67 The data provisioned for session
80 68 establishment is typically used by various
81 69 downstream SIP signaling systems to route a
82 70 call to the next hop associated with the
83 - called domain. These systems typically use a
84 - local data store ("Local Data Repository"= ) as
85 - their source of session routing information.
86 - More specifically, the SED data is the set of
87 - parameters that the outgoing signaling path
88 - border elements (SBEs) need to initiate the
89 - session. See [RFC5486] for more details.
90 -
71+ called domain. These systems typically use
72+ a local data store ("Local Data Repository&q= uot;)
73+ as their source of session routing
74+ information. More specifically, the SED data
75+ is the set of parameters that the outgoing
76+ signaling path border elements (SBEs)
77+ need to initiate the session. See [RFC5486]
78+ for more details.
91 79
92 80 A "terminating" SIP Service Provider (S= SP)
93 81 provisions SED into the registry to be
94 - selectively shared with other SSPs.
82+ selectively shared with other peer SSPs.
95 83 Subsequently, a registry may distribute the
96 - provisioned data into local data repositories
97 - used for look-up queries (identifier -> URI)
98 - or for lookup and location resolution
99 - (identifier -> URI -> ingress SBE of
100 - terminating SSP). In some cases, the
101 - registry may additionally offer a central
102 - query resolution service (not shown in the
103 - above figure). Typically, this query
104 - resolution service will be something like an
105 - ENUM [RFC 3761] server or a SIP [RFC 3261]
106 - proxy or redirect server.
107 -
84+ provisioned data into local data
85+ repositories used for look-up queries
86+ (identifier -> URI)or for lookup and
87+ location resolution (identifier -> URI -> <= /td>
88+ ingress SBE of terminating SSP). In some
89+ cases, the registry may additionally offer a
90+ central query resolution service (not shown
91+ in the above figure).
108 92
109 - The roles of "client" and "server&q= uot; are
110 - abstract and only apply to the requesting and
111 - responding roles in given transactions and
112 - are not related in any way to the type of
113 - entity participating in a protocol exchange.
114 - For example, a registry might also include a
115 - "client" when such a registry initiates a=
116 - connection (for example, for data
117 - distribution to an SSP).
--e89a8ff1c4aea4092e04bd720e0e-- From dschwartz@xconnect.net Sun Apr 15 02:30:59 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62221F85B7 for ; Sun, 15 Apr 2012 02:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hkfVbrZ-eRX for ; Sun, 15 Apr 2012 02:30:58 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BC21F861B for ; Sun, 15 Apr 2012 02:30:53 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Sun, 15 Apr 2012 12:30:52 +0300 From: David Schwartz To: "Cartwright, Ken" Date: Sun, 15 Apr 2012 12:30:59 +0300 Thread-Topic: [drinks] Recap on Proposed change to Framework intro Thread-Index: Ac0a6nM0FTvd/NRLSiKMjijr/YOtmQ== Message-ID: <8BA56B06-7E6D-493C-A266-70E8FC061168@xconnect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8BA56B067E6D493CA26670E8FC061168xconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" , Dean Willis Subject: Re: [drinks] Recap on Proposed change to Framework intro X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 09:30:59 -0000 --_000_8BA56B067E6D493CA26670E8FC061168xconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ken On Apr 11, 2012, at 10:58 PM, Cartwright, Ken wrote: Hi Dean, 1) Can you please identify the diffs. Thanks. 2) From a general perspective, the framework supports what it supports. So= adding in text to somehow further bound or expand on that seems un-necessa= ry. DS: Unless the additional text neither bounds or expands but merely adds so= me necessary clarification. It is certainly true that neither the Use Case document nor the resulting f= ramework or protocol documents have attempted to include or support all typ= es of use cases that can be involved on route generation and selection (e.g= . Time Based Route Selection, Dial Plans, etc, etc). Early on, the scope w= as deemed to be more limited than that, because that broader scope would ha= ve been too large, and moving, and varying. If we wish to expand the scope= covered by the Use Case document and/or the framework then that is a diffe= rent matter. But adding in vague language here that seems to sort-of apolo= gize for the scope seems a little odd to me. DS: Why do you feel that the new text is apologetic or vague? I would count= er that the term peering is way more vague than access control which is pre= cisely what is described in the current docs. 3) Introduction of the word =93targeting=94 cries out for a definition. Af= aik, this is a term that has not been defined here or in another document. = But if that definition does exist then can you point us at it. Thanks. I= don=92t think we can get away with just =93slipping it in=94 here. It=92s= just too noticeable when used in this context. DS: The DRINKS WG is predicated on the SPEERMINT WG and specifically on RFC= 5486 defining the very terms we use in our use case document. Section 4.3.= 3 of 5486 defines LUF (covered as well in section 3.3 of RFC 6461 - the DRI= NKS use case doc) and in the definition of LUF the term "target" is quite d= eliberate=85"The Look-Up Function (LUF) determines for a given request the = target domain to which the request should be routed", hence one could say t= hat "targeting" is the process of determining the target. If the definition= of "target" is unclear than that is a problem with 5486 more than it is wi= th any of the DRINKS docs. 4) The phrase =93commercial peering =93clearinghouse=94 operation=94 could = probably be either removed or altered. For example, whether the implementi= ng registry is =93commercial=94 or not is not relevant, and whether the imp= lementing registry considers itself a =93clearinghouse=94 is not relevant. DS: It depends in which document. I would agree that in both framework and = protocol docs there is no place for either term. I would argue, however, th= at in a use case document, these terms are very relevant as they provide co= ntext to the relevant use cases. Thanks for considering these points. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, April 11, 2012 10:38 AM To: drinks@ietf.org Subject: [drinks] Recap on Proposed change to Framework intro Recapping from the discussion we had on the list. I believe the following m= ight suffice for getting the concerns raised by David about the scope of "p= eering" into the document. I'm personally still vague on the difference between routing and targeting,= but I don't think that matters much for this text. 1. Introduction Service providers and enterprises use registries to make session routing/ta= rgeting decisions for Voice over IP, SMS and MMS traffic exchanges. This do= cument is narrowly focused on the provisioning framework for these registri= es. In other words, the goal is to allow users to put session establishmen= t data (SED) into a registry, to share that SED selectively with other user= s of that registry, and to allow those other users to further select a subs= et of that SED for use in their own applications. The requirements and use= cases driving this framework have been documented in [RFC 6461], and the r= eader is expected to be familiar with the terminology defined therein. The SED described in this framework is limited to simple routing/targeting = data. Although the terms "peer" and "peering" are used, these refer only to= the sharing of basic call routing/targeting information between users of t= he registry, and do not address the broad range of policy factors that migh= t be used in a commercial peering "clearinghouse" operation. In short "peer= ing organizations" are other users of the same registry, and "peers" are us= ers of that registry to whom the offer of sharing specific SED has been ext= ended, and who have accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from regis= try, registry to local data repository and registry to registry, as shown h= ere: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This docum= ent defines an abstract framework for the interaction of registry clients w= ith registries, referred to as the Session Peering Provisioning Framework (= SPPF). This abstract framework is to be mapped into specific protocol bind= ings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by various= downstream SIP signaling systems to route a call to the next hop associate= d with the called domain. These systems typically use a local data store (= "Local Data Repository") as their source of session routing information. M= ore specifically, the SED data is the set of parameters that the outgoing s= ignaling path border elements (SBEs) need to initiate the session. See [RF= C5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the registry= to be selectively shared with other SSPs. Subsequently, a registry may dis= tribute the provisioned data into local data repositories used for look-up = queries (identifier -> URI) or for lookup and location resolution (identifi= er -> URI -> ingress SBE of terminating SSP). In some cases, the registry = may additionally offer a central query resolution service (not shown in the= above figure). Typically, this query resolution service will be something = like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server= . The roles of "client" and "server" are abstract and only apply to the requ= esting and responding roles in given transactions and are not related in an= y way to the type of entity participating in a protocol exchange. For exam= ple, a registry might also include a "client" when such a registry initiate= s a connection (for example, for data distribution to an SSP). ... continue with existing text from "A key requirement..." ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_8BA56B067E6D493CA26670E8FC061168xconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Ken

=
On Apr 11, 2012, at 10:58 PM, Cartwright, Ken wrote:

Hi Dean,

<= p class=3D"MsoNormal"> 

1) Can you please identify the diffs. =  Thanks.

2) From a general perspective, the fra= mework supports what it supports.  So adding in text to somehow furthe= r bound or expand on that seems un-necessary. 


DS: Unless the additional text neither bounds or = expands but merely adds some necessary clarification.

It is certainly true that neither the= Use Case document nor the resulting framework or protocol documents have a= ttempted to include or support all types of use cases that can be involved = on route generation and selection (e.g. Time Based Route Selection, Dial Plans, etc, etc).  Early on, the scope was deem= ed to be more limited than that, because that broader scope would have been= too large, and moving, and varying.  If we wish to expand the scope c= overed by the Use Case document and/or the framework then that is a different matter.  But adding in vague langu= age here that seems to sort-of apologize for the scope seems a little odd t= o me.


<= /div>DS: Why do you feel that the new text is apologetic or vague? I would = counter that the term peering is way more vague than access control which i= s precisely what is described in the current docs.

3) Introduction of the word =93targeti= ng=94 cries out for a definition.  Afaik, this is a term that has not = been defined here or in another document.  But if that definition does exist then can you point us at= it.  Thanks.  I don=92t think we can get away with just =93slipp= ing it in=94 here.  It=92s just too noticeable when used in this conte= xt.


DS: The DRINKS WG is predicated on the SPEERMINT WG and specifically on = RFC 5486 defining the very terms we use in our use case document. Section 4= .3.3 of 5486 defines LUF (covered as well in section 3.3 of RFC 6461 - the = DRINKS use case doc) and in the definition of LUF the term "target" is quit= e deliberate=85"The Look-Up Function (LUF) determines for a give= n request the target domain to which the request should b= e routed", hence one could say that "targeting" is the process of de= termining the target. If the definition of "target" is unclear than that is= a problem with 5486 more than it is with any of the DRINKS docs.

<= /div>

=

4) The phrase =93commercial peering = =93clearinghouse=94 operation=94 could probably be either removed or altere= d.  For example, whether the implementing registry is =93commercial=94 or not is not relevant, and whether the imple= menting registry considers itself a =93clearinghouse=94 is not relevant. &n= bsp;


DS: It depends in which document. I would agree that in both framework = and protocol docs there is no place for either term. I would argue, however= , that in a use case document, these terms are very relevant as they provid= e context to the relevant use cases.

 

Thanks for considering these points.

Ken

 

From: drinks-bounces@ietf.org [mailto:= drinks-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Wednesday, April 11, 2= 012 10:38 AM
To: drinks@ietf.org=
Subject: [drinks] Recap on P= roposed change to Framework intro

 

Recapping from the discussion we had on the list. I = believe the following might suffice for getting the concerns raised by Davi= d about the scope of "peering" into the document.

 

I'm personally still vague on the difference between= routing and targeting, but I don't think that matters much for this text.<= /span>

 

 

1.  Introduction

 

Service providers and enterprises use registries to = make session routing/targeting decisions for Voice over IP, SMS and MMS tra= ffic exchanges. This document is narrowly focused on the provisioning framework for these registries. &n= bsp;In other words, the goal is to allow users to put session establishment= data (SED) into a registry, to share that SED selectively with other users= of that registry, and to allow those other users to further select a subset of that SED for use in their own ap= plications.  The requirements and use cases driving this framework hav= e been documented in [RFC 6461], and the reader is expected to be familiar = with the terminology defined therein.

 

The SED described in this framework is limited to si= mple routing/targeting data. Although the terms "peer" and "peering" are us= ed, these refer only to the sharing of basic call routing/targeting information between users of t= he registry, and do not address the broad range of policy factors that migh= t be used in a commercial peering "clearinghouse" operation. In short "peer= ing organizations" are other users of the same registry, and "peers" are users of that registry to whom the o= ffer of sharing specific SED has been extended, and who have accepted that = offer.

 

Three types of data flows are described in [RFC 6471= ]: client to/from registry, registry to local data repository and registry = to registry, as shown here:

 

 

 

    *--------*        =       *------------*           &nb= sp;   *------------*

    |        | (1). Cl= ient   |            | (3).Registry  = ;|            |

    | Client | <-----------> |  = ;Registry  |<------------->|  Registry  |

    |        |   = to Registry |            |  to Registry =  |            |=

    *--------*        =       *------------*           &nb= sp;   *------------*

              &nb= sp;                   /  = \                     &nb= sp;    \

              &nb= sp;                  /   =  \                   &nbs= p;      \

              &nb= sp;                 /    =  \                   &nb= sp;      \

              &nb= sp;                /     =    \                 &nbs= p;        v

              &nb= sp;               /      =    \                 &nb= sp;       ...

              &nb= sp;              /       =      \

              &nb= sp;             / (2). Distrib \

              &nb= sp;            / Registry data  \=

              &nb= sp;           /  to local data   \

              &nb= sp;          V      store   &n= bsp;     V

              &nb= sp;     +----------+         +----------+

              &nb= sp;     |Local Data|         |Local Data|

              &nb= sp;     |Repository|         |Repository|

              &nb= sp;     +----------+         +----------+

 

              &nb= sp;      Three Registry Provisioning Flows

 

 

This document addresses only the (1) Client to Regis= try aspect.  This document defines an abstract framework for the inter= action of registry clients with registries, referred to as the Session Peering Provisioning Framework= (SPPF).  This abstract framework is to be mapped into specific protoc= ol bindings in other documents, initially to SOAP in [draft-ietf-drinks-spp= -soap].

 

The data provisioned for session establishment is ty= pically used by various downstream SIP signaling systems to route a call to= the next hop associated with the called domain.  These systems typically use a local data sto= re ("Local Data Repository") as their source of session routing information= .  More specifically, the SED data is the set of parameters that the o= utgoing signaling path border elements (SBEs) need to initiate the session.  See [RFC5486] for more details.=

 

A "terminating" SIP Service Provider (SSP) provision= s SED into the registry to be selectively shared with other SSPs. Subsequen= tly, a registry may distribute the provisioned data into local data repositories used for look-up queries= (identifier -> URI) or for lookup and location resolution (identifier -= > URI -> ingress SBE of terminating SSP).  In some cases, the re= gistry may additionally offer a central query resolution service (not shown in the above figure). Typically, this query = resolution service will be something like an ENUM [RFC 3761] server or a SI= P [RFC 3261] proxy or redirect server.

 

The roles of  "client" and "server" are abstrac= t and only apply to the requesting and responding roles in given transactio= ns and are not related in any way to the type of entity participating in a protocol exchange.  For = example, a registry might also include a "client" when such a registry init= iates a connection (for example, for data distribution to an SSP).

 

... continue with existing text from "A key requirem= ent..."


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.
<ATT00001..c>

= --_000_8BA56B067E6D493CA26670E8FC061168xconnectnet_-- From dean.willis@softarmor.com Wed Apr 18 07:52:11 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3102A21F854D for ; Wed, 18 Apr 2012 07:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIyM6BrelaO7 for ; Wed, 18 Apr 2012 07:52:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C796E21F8539 for ; Wed, 18 Apr 2012 07:52:06 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so6123131obb.31 for ; Wed, 18 Apr 2012 07:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to:mime-version:x-mailer; bh=CfSmr6FD8VhIGsdYtqh6uf83t2pMMs6bHTA55Z263hY=; b=HFwYUOxFyoKCCSWivw84Z03hm30I4dbOUqOAQPbfC4lvVgWWix+DbzPXvwOz0O0C2W 1XbaeJvJYrVc9D0hYC3APIkTfVlMHu5uTZaG0EPPYZ3sjlAz8NE8VTFIernkUOFwbMnw poT8wIXat6g3qi+HWdlRAw0K6PKOLyzw9qMGw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to:mime-version:x-mailer :x-gm-message-state; bh=CfSmr6FD8VhIGsdYtqh6uf83t2pMMs6bHTA55Z263hY=; b=kXHacO/KBlYea6F6o6BSSbh3fC8XKUhnlnSvGYJkg2hwHS3YgTInuwwygXuG9aGkDb OhOCJLYudqD6lJrWfQBQ1W3yHw5UYdhCM4Cyk/tOiHiTeZElvc0QUOsTpFzUOI+Rjjhe JEDMWWGLx0mPVaKPFReLgqLoE8cgawE5Noxfqg/IHHDK2CjAkk/qlOFZtEZbVmFSO/Ju 8pTOpNSBRP2BsPcMyaFZHMNGlD9XPXCZg31uQ6hsDqvkhlry9BxINogapeGV1rovY7lb Q5aUnT0F2pHQRAW9NUbbkywoxeNEmmSSmHwLI7J8fvxrOXE2KkvRJ3G4NnvolhmPSKDr z29w== Received: by 10.182.40.70 with SMTP id v6mr3497838obk.39.1334760726172; Wed, 18 Apr 2012 07:52:06 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id k7sm21787330oei.0.2012.04.18.07.52.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 07:52:05 -0700 (PDT) From: Dean Willis Content-Type: multipart/alternative; boundary=Apple-Mail-31--28762642 Message-Id: <035818E5-6AF6-4FD5-8C9D-83AA690D774E@softarmor.com> Date: Wed, 18 Apr 2012 09:52:02 -0500 To: drinks@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn1Ou5/0YE4NpRRSH7xK9Pcz/c+jo4CHzEGo6UL0WOXwydgTo1G9wZIxrHtFnV5S4hys323 Subject: [drinks] More polishing on intro based on discussion between Ken and David X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:52:11 -0000 --Apple-Mail-31--28762642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ken and David wrangled on "targeting". David provided references, and I've been looking at those. We seem to be = talking about two things that are both "routing" in RFC 3261. But SIP = has no "lookup" function, just a redirect response to a "send" function = that's been perverted as a lookup function, and that dual-usage is part = of what makes the discussion confusing. In other words, sending an = INVITE to a server that is going to send back a 302 is "routing", but = we're David is calling it "targeting" in his terminology. So here's what I'm thinking we have: Starting with a "query" protocol that is distinct from a = session-establishment protocol: LUF returns another place at which we need to do a query.=20 LRF returns a session-protocol destination towards which we would issue = a session-estabishment request (aka, SIP INVITE). Both might also return "seed" information for the second query, = basically some sort of regex transformation that we might apply to the = querystring. Confusingly, I think we think that SIP can be both a query protocol and = a session-establishment protocol. This requires a priori knowledge that = the target-URI of a SIP INVITE request is not a UA with which one wishes = to establish a session, but is actually a "location server" that is = expected to send a 302 response. In other words, if it sent a 200 OK, = you'd be very confused and have some kind of call failure. If we have = this assumption, then we cannot tell by examination of a naked target = URI whether that URI is to be used as an LRF or an LUF. We need = additional metadata telling us how to use that URI, and we get this from = the schema. In other words, if we send a query to a server using our "query" = protocol and said server responds with a naked SIP URI, we don't know = whether we should treat that SIP URI as an LRF or an LUF, and we really = need to know, because those are two very different use cases. The other option is to follow the "if it hurts, stop doing it" model and = assume that a SIP URI is a SIP URI; that is, it is always a LRF and not = a LUF. Even if in practice it responds with a 302 to another domain. = Note that SIP does not have a regex-transform 302 response. Anyhow, with that in mind, let's see if the Intro can be made to make = any more sense Please excuse my use of MHTML. People seem to want diff-indicators so = they can see what has changed. Here I have struck-out excised text, and = placed new text in an oblique (italic) font. 1. Introduction Service providers and enterprises use registries to make session = routing/targeting establishment decisions for Voice over IP, SMS and MMS = traffic exchanges. This document is narrowly focused on the provisioning = framework for these registries. In other words, the goal is to allow = users to put session establishment data (SED) into a registry, to share = that SED selectively with other users of that registry, and to allow = those other users to further select a subset of that SED for use in = their own applications. The requirements and use cases driving this = framework have been documented in [RFC 6461], and the reader is expected = to be familiar with the terminology defined therein. Additional = vocabulary, particularly location-routing function (LRF) and look-up = function (LUF) are as defined in RFC 5486. The SED described in this framework is limited to simple = routing/targeting LUF and LRF data, typically expressed as URIs along = with supporting metadata. Although the terms "peer" and "peering" are = used, these refer only to the sharing of basic call routing/targeting = LRF and LUF information between users of the registry, and do not = address the broad range of policy factors that might be used in a = commercial peering "clearinghouse" an operation driven by more complex = criteria such as cost, differential routing by time of day, QoS, or the = many other factors that might be negotiated in a peering agreement. In = short "peering organizations" are other users of the same registry, and = "peers" are users of that registry to whom the offer of sharing specific = SED has been extended, and who have accepted that offer. Three types of data flows are described in [RFC 6471]: client to/from = registry, registry to local data repository and registry to registry, as = shown here: *--------* *------------* *------------* | | (1). Client | | (3).Registry | | | Client | <-----------> | Registry |<------------->| Registry | | | to Registry | | to Registry | | *--------* *------------* *------------* / \ \ / \ \ / \ \ / \ v / \ ... / \ / (2). Distrib \ / Registry data \ / to local data \ V store V +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ Three Registry Provisioning Flows This document addresses only the (1) Client to Registry aspect. This = document defines an abstract framework for the interaction of registry = clients with registries, referred to as the Session Peering Provisioning = Framework (SPPF). This abstract framework is to be mapped into specific = protocol bindings in other documents, initially to SOAP in = [draft-ietf-drinks-spp-soap]. The data provisioned for session establishment is typically used by = various downstream SIP signaling systems to route a call to the next hop = associated with the called domain. These systems typically use a local = data store ("Local Data Repository") as their source of session routing = information. More specifically, the SED data is the set of parameters = that the outgoing signaling path border elements (SBEs) need to initiate = the session. See [RFC5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the = registry to be selectively shared with other SSPs. Subsequently, a = registry may distribute the provisioned data into local data = repositories used for look-up queries (identifier -> URI) or for lookup = and location resolution (identifier -> URI -> ingress SBE of terminating = SSP). In some cases, the registry may additionally offer a central = query resolution service (not shown in the above figure). Typically, = this query resolution service will be something like an ENUM [RFC 3761] = server or a SIP [RFC 3261] proxy or redirect server. The roles of "client" and "server" are abstract and only apply to the = requesting and responding roles in given transactions and are not = related in any way to the type of entity participating in a protocol = exchange. For example, a registry might also include a "client" when = such a registry initiates a connection (for example, for data = distribution to an SSP). ... continue with existing text from "A key requirement..."= --Apple-Mail-31--28762642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

David provided references, and = I've been looking at those. We seem to be talking about two things that = are both "routing" in RFC 3261.  But SIP has no "lookup" function, = just a redirect response to a "send" function that's been perverted as a = lookup function, and that dual-usage is part of what makes the = discussion confusing. In other words, sending an INVITE to a server that = is going to send back a 302 is "routing", but we're David is calling it = "targeting" in his terminology.

So here's what = I'm thinking we have:

Starting with a "query" = protocol that is distinct from a session-establishment = protocol:

LUF  returns another place at = which we need to do a query. 

LRF =  returns a session-protocol destination towards which we would = issue a session-estabishment request (aka, SIP = INVITE).

Both might also return "seed" = information for the second query, basically some sort of regex = transformation that we might apply to the = querystring.

Confusingly, I think we think that = SIP can be both a query protocol and a session-establishment protocol. = This requires a priori knowledge that the target-URI of a SIP INVITE = request is not a UA with which one wishes to establish a session, = but is actually a "location server" that is expected to send a 302 = response. In other words, if it sent a 200 OK, you'd be very confused = and have some kind of call failure. If we have this assumption, then we = cannot tell by examination of a naked target URI whether that URI is to = be used as an LRF or an LUF. We need additional metadata telling us how = to use that URI, and we get this from the = schema.

In other words, if we send a query to a = server using our "query" protocol and said server responds with a naked = SIP URI, we don't know whether we should treat that SIP URI as an LRF or = an LUF, and we really need to know, because those are two very different = use cases.

The other option is to follow the = "if it hurts, stop doing it" model and assume that a SIP URI is a SIP = URI; that is, it is always a LRF and not a LUF. Even if in practice it = responds with a 302 to another domain. Note that SIP does not have a = regex-transform 302 = response.


Anyhow, with that in = mind, let's see if the Intro can be made to make any more = sense

Please excuse my use of MHTML. People = seem to want diff-indicators so they can see what has changed. Here I = have struck-out excised text, and placed new text in an oblique (italic) = font.


1. =  Introduction

Service providers and enterprises use = registries to make session = routing/targeting establishment decisions = for Voice over IP, SMS and MMS traffic exchanges. This document = is narrowly focused on the provisioning framework for these = registries.  In other words, the goal is to allow users to put = session establishment data (SED) into a registry, to share that SED = selectively with other users of that registry, and to allow those other = users to further select a subset of that SED for use in their own = applications.  The requirements and use cases driving this = framework have been documented in [RFC 6461], and the reader is expected = to be familiar with the terminology defined therein. Additional = vocabulary, particularly location-routing function (LRF) and look-up = function (LUF) are as defined in RFC 5486.

The SED described = in this framework is limited to simple = routing/targeting LUF and LRF data, typically expressed = as URIs along with supporting metadata. Although the terms "peer" = and "peering" are used, these refer only to the sharing of = basic call routing/targeting LRF and LUF = information between users of the registry, and do not address the broad = range of policy factors that might be used in a commercial = peering "clearinghouse" an operation driven by = more complex criteria such as cost, differential routing by time of day, = QoS, or the many other factors that might be negotiated in a peering = agreement. In short "peering organizations" are other users of the = same registry, and "peers" are users of that registry to whom the = offer of sharing specific SED has been extended, and who have accepted = that offer.

Three types of data flows are described in [RFC = 6471]: client to/from registry, registry to local data repository and = registry to registry, as shown here:



    = *--------*               = *------------*               = *------------*
    |        | (1). = Client   |            | (3).Registry =  |            |
    | = Client | <-----------> |  Registry =  |<------------->|  Registry  |
    | =        |   to Registry |       =      |  to Registry  |       =      |
    *--------*       =         *------------*         =       *------------*
        =                     =       /  \             =              \
    =                     =          /    \       =                   =  \
                =                 /     =  \                   =        \
          =                     =  /        \           =                v
  =                     =         /          \   =                     =   ...
                =              /       =      \
            =                 / (2). Distrib = \
                  =          / Registry data  \
  =                     =     /  to local data   \
      =                    V =      store         V
    =                 +----------+ =         +----------+
        =             |Local Data|     =     |Local Data|
            =         |Repository|         = |Repository|
                =     +----------+         = +----------+

              =        Three Registry Provisioning = Flows


This document addresses only the (1) Client to Registry = aspect.  This document defines an abstract framework for the = interaction of registry clients with registries, referred to as the = Session Peering Provisioning Framework (SPPF).  This abstract = framework is to be mapped into specific protocol bindings in = other documents, initially to SOAP in = [draft-ietf-drinks-spp-soap].

The data provisioned for session = establishment is typically used by various downstream SIP signaling = systems to route a call to the next hop associated with the called = domain.  These systems typically use a local data store ("Local = Data Repository") as their source of session routing information. =  More specifically, the SED data is the set of parameters that = the outgoing signaling path border elements (SBEs) need to initiate the = session.  See [RFC5486] for more details.

A "terminating" = SIP Service Provider (SSP) provisions SED into the registry to be = selectively shared with other SSPs. Subsequently, a registry may = distribute the provisioned data into local data repositories used = for look-up queries (identifier -> URI) or for lookup and location = resolution (identifier -> URI -> ingress SBE of terminating = SSP).  In some cases, the registry may additionally offer a central = query resolution service (not shown in the above figure). Typically, = this query resolution service will be something like an ENUM [RFC = 3761] server or a SIP [RFC 3261] proxy or redirect server.

The = roles of  "client" and "server" are abstract and only apply to the = requesting and responding roles in given transactions and are not = related in any way to the type of entity participating in a = protocol exchange.  For example, a registry might also include a = "client" when such a registry initiates a connection (for example, = for data distribution to an SSP).

... continue with existing text = from "A key requirement..."
= --Apple-Mail-31--28762642-- From sumanth@cablelabs.com Sun Apr 22 16:40:28 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADA21F85F7 for ; Sun, 22 Apr 2012 16:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.837 X-Spam-Level: X-Spam-Status: No, score=0.837 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amScLhfFlduo for ; Sun, 22 Apr 2012 16:40:27 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 93F1521F85D6 for ; Sun, 22 Apr 2012 16:40:27 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q3MNeQbC030564 for ; Sun, 22 Apr 2012 17:40:26 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sun, 22 Apr 2012 17:40:26 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Sun, 22 Apr 2012 17:40:26 -0600 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Sun, 22 Apr 2012 17:40:24 -0600 Thread-Topic: Minutes Posted Thread-Index: Ac0g4SUXsULKXqgVSkW4YAq525pMnA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F2CF32BAF@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Minutes Posted X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 23:40:28 -0000 As a follow-up, I have now posted the draft minutes at: http://www.ietf.org= /proceedings/83/minutes/minutes-83-drinks.rtf=20 Please take a few minutes to review and provide any additions and correctio= ns. Thanks! - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Sumanth Channabasappa Sent: Thursday, March 29, 2012 10:14 AM To: drinks@ietf.org Subject: [drinks] Draft minutes Folks, Thanks again to everyone who participated today (in-person or remotely)! Ou= r volunteer note-taker's (Brian Rosen - many thanks!) draft notes can be f= ound at: http://tools.ietf.org/wg/drinks/minutes=20 Please feel free to make corrections or changes directly. Alex and I will c= urate it in the upcoming days.=20 Also, sorry about the challenges with remote participation - not having a w= ired connection made for a bad connection.=20 - S=20 _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks