From sigtran-bounces@ietf.org Fri Mar 02 00:18:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN09q-00072b-7J; Fri, 02 Mar 2007 00:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN09o-00072P-LI for sigtran@ietf.org; Fri, 02 Mar 2007 00:18:16 -0500 Received: from [211.179.3.4] (helo=mail.inticube.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN09n-0005kH-7R for sigtran@ietf.org; Fri, 02 Mar 2007 00:18:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Mar 2007 14:18:18 +0900 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAVA came before ASP_ACTIVE_ACK is coreect? Thread-Index: Acdcii/7GA8OZP5hSUipzs0RK/ctIQ== From: =?ks_c_5601-1987?B?sce1tcf8?= To: X-Spam-Score: 1.0 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Sigtran] DAVA came before ASP_ACTIVE_ACK is coreect? X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0818368646==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============0818368646== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75C89.CA1982F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75C89.CA1982F6 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Dear Sir, We use SUA Layer. (SG vendor is CISCO). When our system is up and sends ASP_ACTIVE to SG, SG response with = ASP_ACTIVE_ACK. But SG sends us DAVA messages before ASP_ACTIVE_ACK message. =20 We discard SNM messages that send before ASP_ACTIVE_ACK. Should we accept these DAVA messages? =20 ------_=_NextPart_001_01C75C89.CA1982F6 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Dear Sir,

We use SUA Layer. (SG vendor is = CISCO).

When our system is up and sends ASP_ACTIVE to = SG, SG response with ASP_ACTIVE_ACK.

But SG sends us DAVA messages before = ASP_ACTIVE_ACK message.

 

We discard SNM messages that send before = ASP_ACTIVE_ACK.

Should we accept these DAVA = messages?

 

------_=_NextPart_001_01C75C89.CA1982F6-- --===============0818368646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0818368646==-- From sigtran-bounces@ietf.org Fri Mar 02 00:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0lc-0007QU-IN; Fri, 02 Mar 2007 00:57:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0la-0007QC-Hf for sigtran@ietf.org; Fri, 02 Mar 2007 00:57:19 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN0lZ-0002BI-2d for sigtran@ietf.org; Fri, 02 Mar 2007 00:57:18 -0500 Received: from ns.pigworks.openss7.net (IDENT:tb8oGyAg2Ix4db5dOFtXFR8evFapWjk3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l225vFZ20611; Thu, 1 Mar 2007 22:57:15 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l225vF215537; Thu, 1 Mar 2007 22:57:15 -0700 Date: Thu, 1 Mar 2007 22:57:14 -0700 From: "Brian F. G. Bidulock" To: =?iso-8859-1?Q?=B1=C7=B5=B5=C7=FC?= Subject: Re: [Sigtran] DAVA came before ASP_ACTIVE_ACK is coreect? Message-ID: <20070301225714.A15329@openss7.org> Mail-Followup-To: =?iso-8859-1?Q?=B1=C7=B5=B5=C7=FC?= , sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from monji@inticube.com on Fri, Mar 02, 2007 at 02:18:18PM +0900 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id l225vFZ20611 X-Spam-Score: 0.8 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org =B1=C7=B5=B5=C7=FC, =B1=C7=B5=B5=C7=FC wrote: (Fri, 02 Mar 20= 07 14:18:18) >=20 > Dear Sir, >=20 > We use SUA Layer. (SG vendor is CISCO). Please do no use vendor names on this list, particularly as it is unimportant to the discussion. >=20 > When our system is up and sends ASP_ACTIVE to SG, SG response wi= th > ASP_ACTIVE_ACK. >=20 > But SG sends us DAVA messages before ASP_ACTIVE_ACK message. >=20 >=20 > We discard SNM messages that send before ASP_ACTIVE_ACK. >=20 > Should we accept these DAVA messages? They can be processed, discarded or ignored. If you assume that all destinations are accessible anyway, there is no difference. The sending = of SNMM messages between ASP Active and ASP Active Ack is intended (and only necessary) to indicate restricted, congested, or inaccessible destination= s. The pertinent passage is RFC 4666/4.5.1: For the particular case that an ASP becomes active for an AS and destinations normally accessible to the AS are inaccessible, restricted, or congested, the SG MAY send DUNA, DRST, or SCON messages for the inaccessible, restricted, or congested destinations to the ASP newly active for the AS to prevent the ASP from sending traffic for destinations that it might not otherwise know that are inaccessible, restricted, or congested. For the newly activating ASP from which the SGP has received an ASP Active message, these DUNA, DRST, and SCON messages MAY be sent before sending the ASP Active Ack that completes the activation procedure. Nevertheless, it makes sense that it might be necessary to send or proces= s a DAVA during that period as well (e.g. if a destination becomes available = after the ASP Active is received but before the ASP Active is sent, and possibl= e after a DUNA has already been sent). --brian --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From Dillion.Seers@audiolink.ch Fri Mar 02 06:41:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN68W-0007gk-Ns for sigtran-archive@lists.ietf.org; Fri, 02 Mar 2007 06:41:21 -0500 Received: from [61.247.251.234] (helo=dsl-Chn-static-234.251.247.61.airtelbroadband.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HN68N-0004Ag-9c for sigtran-archive@lists.ietf.org; Fri, 02 Mar 2007 06:41:20 -0500 Received: from Dillion.Seers@audiolink.ch ( [122.126.44.48]) Fri, 2 Mar 2007 17:11:51 +05-30 MIME-Version: 1.0 Message-Id: <1F0CE6EC.000002.00955@> Date: Fri, 2 Mar 2007 17:11:14 +05-30 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_QSX93O0YADM5B2O2QL80" X-Mailer: IncrediMail (5252670) From: "Dillion Seers" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: Ambassador attention X-Spam-Score: 2.2 (++) X-Scan-Signature: 3c5809f82a2ef36c74d8c0ab21f70455 --------------Boundary-00=_QSX93O0YADM5B2O2QL80 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_QSX9TA8YADM5B2O2QL80" --------------Boundary-00=_QSX9TA8YADM5B2O2QL80 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Clearly mourning find joy life.=0D Trademark wikimedia foundation inc nonprofit denise massingill, message boards.=0D Marchapril active meaubrey scheduled pilot onlypunkd helper.=0D Finds comfort, giftpost clearly mourning find.=0D Jokes widely reported end, seriesalso joke opposite rolelohan, photo.=0D West hollywood still spending time dated actor wilmer valderrama.=0D Halle berrythe death altman hard according condolence letter drew.=0D Shy violet lessons, sharon stone kenneth turan.=0D Quickly rushed stores, blend dancepop anthemic, arena rock.=0D Clearly mourning find joy life.=0D =20 --------------Boundary-00=_QSX9TA8YADM5B2O2QL80 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Clearly mourning find joy life.
Trademark wikimedia foundation inc nonprofit denise massingill, message boards.
Marchapril active meaubrey scheduled pilot onlypunkd helper.
Finds comfort, giftpost clearly mourning find.
Jokes widely reported end, seriesalso joke opposite rolelohan, photo.
West hollywood still spending time dated actor wilmer valderrama.
Halle berrythe death altman hard according condolence letter drew.
Shy violet lessons, sharon stone kenneth turan.
Quickly rushed stores, blend dancepop anthemic, arena rock.
Clearly mourning find joy life.
 
3D"FREE<= /HTML> --------------Boundary-00=_QSX9TA8YADM5B2O2QL80-- --------------Boundary-00=_QSX93O0YADM5B2O2QL80 Content-Type: image/jpeg; name="102-EB339E9.jpg" Content-Transfer-Encoding: base64 Content-ID: <55703F44-F9AF-C54E-8761-4336AA39686B> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_QSX93O0YADM5B2O2QL80 Content-Type: image/gif; name="pop17.gif" Content-Transfer-Encoding: base64 Content-ID: <666DFA2D-25F0-3B2B-B1AF-23F503A83BF0> R0lGODlhyAG4AIdBAAAEAIsOCACIBYaNAAAAiosFiwWIfbWyysflv7LI/EMrAGwgB3glAJ0sAL4c ANURAwFCBR1NAElKAVg8AHJGAJxJCL47AOA6AABlABZiADlRAmpdAIRtAaBfDMlhANJbCgtyCxV7 BER2AF2BC4GJC6aOAMiDCNZ7AAmaABKVCTqpAFaSAHmqAJWqBbqUAOqhBAC2CCHGADW4AlO6AHbG AJPFALzNANvNAADtAhLeAj7SAG7nBI3hDq3kALfjDN3sBwMAQC0IQzoCQWkAO3gANpwBRrQETtkH QgcROCAiQDkWRFMXTYolM58rMcIWPOQqOgA9Qho8STpLPFVCN448Oa1EN8A/RetJMwtdNhhYOk1s MmRuPItrA5ptQ7JfP9xcTAx0RhKFTTJ/MVGLR4l/Ppx/Q76DN+ZzNgSmOR6TRkKZMlaVN36tOqOk MrudQNGpOQu5Nyq3SknAP27ATHq/OJ7MOsG/Q9+zNADnTiDfSEzcNVPpS4rZO5LaMcfUOuXYMgcA hR8KfUYAdGEKiHsAc6cAd8sActoAfQghgygoeEwRdmoih40Sg6Uoc8YffOIThQBAfCJMhzxMfWFA eHFLjqM0e8FLiNI0jQRScx5chTZpdlxbjoNkcaRijsFZidlleAZ1cSB6gT2LeFl1jIhzc62EjLSB e+OHfQCTgBalckamgVyjeYCuia6sisingNOteADKdha+gE7MilTKiYLBdq7Bi7fIgNe9fwjpgRnV hzrTdGHXiHnldqDog8jfddflegwAyicAwD0AymAIu4oAupMAsbYAu+gEuwoVtxMgtzcZtW4pyIQf y6Usu78auNsdtgBLtSE1zEc7v19Hzn9GuKM1vcFDvNZJxANsuhRmzUJiv19fxHphxZZRv8VRuuVo vgCExi1ysTiHvmuHs3OIt6WMxcN+weKGuwKWsSWusjaSwWeXwHeps5KktMmVyN2XuA6zuy3EuDGx tGa+yYzCuZK6uvHs66iXoHuDfP8LAAv2AP//AAAA//UA/QD/9fD7+SH5BADcxeYALAAAAADIAbgA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY8V/IEOKHEmypMmTKFOqXMmypcuX MGOe9Eizps2bOHPq3Mmzp0+MMoMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNqdfqzq9evYD1u HUu2rFmmYdOqxXm2rdu3cJeunUu3rt27ePPq3cvXYNy/W/sKHkzYK+DDiBOnLMy4sePHkCNLnky5 suXLNxVr3sy5s+fPoEMvxky6tOnTqFOr9im6tevXsGPLng16te3buHPrVk27t+/fwIMLHw58t2Di yJM/Nc68ufPn0KNLn85T+W/q2C9b324yu3e7TWly/x9PvjzK7+jTq9eoua/59/C5Dla63mb8+y6Z y63PH317vvQBiN+Am4mXlHsB6kXggmgJeKCDRyHIYG017bdXggo+2F9z4YmlYYZISRgihBNOJaJR J6JIYlEJCeVhieflZiFFJRk4IkJBvfiXjTDWqBtiOsbFo5C4Aalda0PCFaSSF6I0wJNPlgRlgSsK t+RbSRanEJRPHgQlQSNN2RKXYgKWYnBZtpWmYmRKGWVIBX35EJlvgsRlmG+W2dmZaHZkZEYdIvSl nAQRag+eA8AkZqFcMjrAQIZCKiadbYpEqZ1R8ZbclVoK2mWk9oAq6aMRyWnpnSGVqWeqXQpEaaOu vv/6qKx0IorqjcYptyZM9p005ar/6BlnqxCBSueoyBqkap0m6TkprYbKOhCrl7pZKUgbHmTdRlYt m+ip31qr6JuOEhotsbESK2qyjAqEqK/efjsqpcO+Oi1MH+Sr7wciZavtcL2KayezwRIM7rjhUuvt weA6uiW6C60r6pfUgpuws+RGtO/G+bqrr0oc80uSv34R2ZO5EBv67kvA/pons6tinDBJwPbrsJcQ p3szu8aS+tK+IgH9jz36LhRyxwUdLXJJGzNNckGe3XprwQnXK5GpFT87c7wMN1uzwCtby67OZGO0 70FI//PxSUKrvXZISn+A0MZo52tUPvk8nZm1r3b/TbPBKi2a7KApq0swrRYD7nfFXocbc51fY/tQ 0QxRfi9IbwdtN9ybY5455597LndGeJdekukmla463rdVBe3isAdusNZUhx0prfWS6W7YsQ/s+OGQ R95S6DVabpDxAxn/eegfM9/5UKsfVHpCq1cfUvWo/4N99SBGNTXVv8/cu5OzB/997S0rzneUyuYc qvvpMu67reqD/DxKxLu9NElvI4880R37X/5eYj2SZM+AeEPgQLbHOnswsIDaS6CLCjMxdKlsfPAS X7zKl6j0iU92HATb30j1Pnq171i7W8kAR5K/Afbvfs7jVwxJl8ADgsSGIsHhSA6outNJ8IZ5E8j0 /ywSoZ1UkITrKuFEKOa3a2UthAgboQhtV60MCq4hyuOYx+4HOrZ1LnMx7KLm9heU6Q2RIGc0SBpT CMR87PCHOYTjG92YI255r2aostfYHNIzEpYQfro7FAYzKMVCgo12Kzkf/p4XMmz9TyCPhCTSANhI /n0RhlyECepwqMM2jgyNDVxgKEEZRDZGkI7CiZzWqoW4xsGqbH/047xkCcv2eUqDiluVzuQnvEGy MJP6E6MlyThG0IXseJP0HzBdkj0bdvKUKXGmHD0JJ1ISMTkv65srZWar9VWzlrnbmTjLhTM/ogx+ VhseMF9ITNF5cWnLYyQ79xdJiEyPmtebZj4huP/POfoQlQgEKK+axCbg5fKgsvKdNq12SyTezoIQ vaXGJkkQygWTactk5zCNWUl3CqWHQhylA0VKSuzFEaCdfOYzkcSpuLxOYaqsX0Kr+VCHQvRRksPi Iy1Xz51SNIyiO1oxP9rDU6JUn/gEYkmjh5A0+rNHQ/PTZnpZxcXlsZU/i6fIKJmQsyFzdJIEa/KQ 5tWxJnOZLHngUQV60mia9CQHLMgaI3KYXcnErmfxYPgUqU6lCROjl8SkWMNK2LqBtZ4NUV1Ii5rU p8JVgitVKVJZojdTqogjtOloUDk2Rs7+kp4a3ajoLjJXxS6WeiINaD9TN9mV4odPE8Ssjz6ilLj/ JU2LX+1o2zrrUZnE9bTAbSpJ5RpK06pxlI6dDV4HStAiTiRGsk3K0SpK0duOLm5p1WEzWztN4pZy pN/17t6Q09I6Ntdk0T2K0hyyxn3S8YFt5Cc026pam7WurlL9UF7+ZMcPDfGBi93eat1b30DZhr/9 dW730Jvgu5WytGts74DHkiv8plfB1ZFNec0L3otsqkpuWe5L8vvhC192vxZecIhFDNUTN7jFBkax fvGSU0DBeLYH1hWIOXzfG1OJxACr7ELuumENs1grRVaukGfEHh//2MRlAROGnjblJrtYxsQ5MmWT POIlV/maKX5xn6BMFC53ubK4IvNZtOya5abl/8tCBkqJxRwa7zA5NXe2MXnNjGQvpznOcp6zlXfk ZwwH+s+r+Q+NmYsjOPdnxnpGNJ7DnGNJA3oujkYNghMNaU1v+tCG1pSZZJTp+pSaRp0+TXc8nGpP WxrVlAb1lWXNItp+Us2xpfNQfjRqINfa12Xm86ql/Gpbh5rWuy7Sp1ndalgfuy55Znaxn3tq9VRb IteGyEgq/Wwwd9vYs/Y2oXFNZGAn27I85nSzqb1ubPea3DER9pbhTZbdZFvb7a4LAfbN737vuyv3 fkjAHbJsV0/b3Zrxt8IJoJKO/Nvc59Z1rgfNYG6HG9wXtwe/6YqUjZ/31wK3CpuvwmvP8PvMHP9h +ME34nF8CzrSFZ90q1sukJZ7XOX5drmlaf4VHUPcLDueeEF43m+NP9zoCh+6vxey74E35CQnRzmW 562QWCNbTfTueNNHcvKo/2PhRwe7Qm6+8LGHfeup5vnTnS6ZgmN8zAdR+8ZtHvV+fx3td8c5Sche doQUneZJHwjdCSB4f0Md71SXeLl7PO6sw8XrIVG4SAD/b7Af3SB1z7ze9970k9e870gvPOE/v/S4 gx7pRRdkzkO+csy4nd1SgXzk7T57vXfd8ocf/eDNTviN513ltPe68Ovud7GT/u+BD/3nRS/6zW97 LdE2OJN+LnuQGL72k+884lOieeznPurKJ73/+Mcf/u9bX/M4t/z4Uz/35KP+8n1X+8eDTerGY/7y zVe67bXvfJR0//z9l33Dt3/Ah3YDWGP3N3rrB3/oB4C/d34OeH7Hl3rv93DyBxn1pmxTUX0RWHvM h3oEgX8huHUH6H+0l3cC2IElaIIE2IF5N4K6V3ntF4MKyH8p+IA3iIDqZn93URUciIICKHkAKIQl wXcfmBAUCIQRuII/mINACHlQSIKWJ4UUOIXkV3WrZxmvh3DfxnsJeH1BuH03uIK5ByfsZ4QgOH4s OIZ4F4UFiH7pd4JT6IIz8XPpJmoxJ20uUX0UmBFU6H1rGIYDSITgh4RnV4MM2IJDuIhFaIMm/9GE 8mGH8VZyGedse7h9kDiJFkFztSd7YAeI3weGnmiBg0eDiCh6Ssh5AQhyfhF0d/hoMMGBmeiDiFde n+iB+neCOCiHZdeHpKiAH9gg9deFb3YYq3gVsxhxLFd6Rxh+FfiGQsiHYsiDeFiJavEbybhiN5F8 cnd5Psd41siFTpYYsOUbhTaO3zh1QaZi6NiOHxKO4mgl8+eOxbEtkqhk80iPayZvLHWPgeGPUgdz +oglABkb/DgajtdnCckZWCgaxbhn7NgpCykVOUGR0jeQMEZxbMcaWVgZL3d1GJmB+Sh01UiQIxmS /3iSmnhpJYmSUeaKK2lxrCiTLklhMBmTAv9Jf4q3eDRZkykZkfuokowGjkOJbj7ZEuXIkztIjOlx lCQJbR1JGRvJEK0HFk75khO5EpQIjxxXlT13lUXZg1G5E/a1kzgJkq8IlRBJZWM5ZG0JNZGYlQgJ lEHJknrIlax3HWwxlRnmlXbZl0zZldQIHm/pGNE3HQ1XkEipmFiRlEqJlviogYGpc3hJcFv4kGC5 mJI5mZbZjo4ZkDkpkUSpk2Y5ISMHXXRpjsPImWvnmXI5l+oId1pYFQfpkK9JFZ8ZmYv2bqX5k6Ep mrtZa5epbadJm4yplUJpZFaZmJi1YbDHmlRpdXRxmJYoj8cJmz35lHeZmajZm7BRm925lJX/2Zp+ +RPSKW7WeZvDtpkzmS3DSZnr6J2aOZpYx54mqZ6eUZx1+Jcbkh/keWuYOZ+Nxpu/qZ2mwZf8uZwC WqBAB57rGZx5mKAKCp3ROZjbqYwMShuI+ZiEWZj/QqAZyp3fpBNp+XakKZYeWjIgqpYDMqHj+Z/t 2aEU6pbl2XYfKaMvWqEz2hPU+VxoZpMNuaOAKaQfWqMcGSIp+hwIqqJGyqNJCpdN6qREyp9LyqQ5 eqRRWqRTCqURKqEwGqPoCabT+aTEtqXjZaZ2WaVceqVSmqVaeqI4yqapeabaKJ+JB6EssqIsKqdk qaaXY6FhiqF4aqAmSqjQ56cBg6Z/2qXV/wmnQGGfjrqnYoppiKp6gNqok0oR/LCp4hmpY6pfmfqc oSqYjFqomrip/OAvPXqN52mUuOmgFtlfqDqqTUmmiTqOsIpjHIGqF7GplWpvv3qd91EhzsWrFmGs doqcerOqAYqrHoGsmsqpyemfP1qiqdliqJqt/FAS2joS2coX0HqhhuqlkfGenamt2SoS6DqrILGu /zCr6dqu3RoS3/qs0oqibkqug1pmSxGv8fquviqv20qv3bqu22qwAwuw7uqt/yqwCrut9hCuF+mp +ood0Gqs4Yqs7CqwCeuwHMux6EqwC/uw6TqyDBuy6nqv9EmtFRunRbGxCuuxIiuyBJGxKv8bsdLK qzMrsxvbsCQbsCSBsCk7ryI7r9raskhLo0gBs+wKszErs09btAs7qzXLqTabqjiLtWDitEHbtFxL tD+LsAlrsAdalkmLpUnBtAHrtD0LtFELsijLtr4qtwPLtVm7EBd7s6rXtmvrr15rshwqqRR7tov6 a3mLtVc7EGrbsW/btYwLr277tFzbuI47tN6quPd6uFWbqv/qs0B6rWfZn1HVEZorEBqrsqWLuVp7 EDo7s3QLtTt7EosrtZ3rtrObuIFan6ALmp1KFLMLt4u7uQZhs6Z7s7yKuxJLuSdruWHLt8zrsGLL uGEprnUZm4JKmDSRusUrsVk7t5HbvH2gm7niq7Wnu7qqi7eom7OcGru/C71iq7vJapzTyrL4abYZ cbTc273lO7JCC7tDg7t3e74BvL0CTMDnO7l1BnDCGp74mq+uaq0Qcbzce7TCCzVxC7S/W6/1OsAc jLHmq5G2urIQzKpLG70mjLIv66s1QcHlW8HbS7TtK7nG+8FhEayryaclU78ne8I8LL2DOxHoWsAd nL4oHLqC+8PWthQBAQA7 --------------Boundary-00=_QSX93O0YADM5B2O2QL80 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: <7854EC56-5FC9-80E4-1D1B-D61BCF03C45F> R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_QSX93O0YADM5B2O2QL80-- From yylnotbd@cablespeed.com Sun Mar 04 17:20:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNz4M-0006Qz-0F for sigtran-archive@lists.ietf.org; Sun, 04 Mar 2007 17:20:42 -0500 Received: from cmu-24-35-126-173.mivlmd.cablespeed.com ([24.35.126.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNz4K-0006Jg-PA for sigtran-archive@lists.ietf.org; Sun, 04 Mar 2007 17:20:41 -0500 From: "You need" To: sigtran-archive@lists.ietf.org Subject: Unusual Volume Date: Sun, 4 Mar 2007 17:20:40 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C75E81.6EE32300" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdegW7j+4xMZdcLTzadJGfq7bkYfw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 4.7 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0000_01C75E81.6EE32300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GDKI IS GETTING READY FOR ANOTHER HUGE BREAKDANCE MONDAY!
HIP-HOP is more than just music... HIP-HOP IS A CULTURE!

GOLDMARK IND - www [dot] goldmarkentertainment [dot] com

CHECK *GDKI* OUT ON - MONDAY FEB 05 2007
RADAR: GDKI
SHARES OPEN MON AT: $0.105

GOLDMARK INDUSTRIES, specializes in the production and distribution of Music, Feature Films and Television entertainment for North America's most rapidly growing demographic, with a total consumer-based purchasing power of over 1 Trillion dollars: the Hip-Hop community.

GDKI THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON 03/05/07!
HABANA.. HABANA.. HABANA BLUES!!
------=_NextPart_000_0000_01C75E81.6EE32300-- From Eti-Nikes@ardernhealthcare.co.uk Sun Mar 04 17:34:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNzHy-00040G-RC for sigtran-archive@lists.ietf.org; Sun, 04 Mar 2007 17:34:47 -0500 Received: from host201-180.pool82104.interbusiness.it ([82.104.180.201]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNzHv-0007Q6-Lm for sigtran-archive@lists.ietf.org; Sun, 04 Mar 2007 17:34:46 -0500 Received: from raffaella (unknown [179.196.166.25]) by Eti-Nikes@ardernhealthcare.co.uk (Postfix) with ESMTP id E76CD25A62A9 for ; Sun, 4 Mar 2007 23:46:52 +0100 Message-ID: <000c01c75eae$f0af28c0$c9b46852@raffaella> From: "Eti Nikes" To: sigtran-archive@lists.ietf.org Subject: heavy traffic US Monterey Date: Sun, 4 Mar 2007 23:46:25 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C75EB7.523B1BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 27216fd639035830d9361a5ade4ff99c ------=_NextPart_000_0008_01C75EB7.523B1BA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C75EB7.523B1BA0" ------=_NextPart_001_0009_01C75EB7.523B1BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Websters robbery seas sea violence lawful. Faxt ctivation gmaeyel invitarion. Penciled brandon iron man ii. Fix, adjusting, reg simulate utility. Wrote audits retina, scanner = principal consultant stake. Pakistan india pledges current view. Holerdquo forcing encryption algorithms, unaware pushing hd routines. Froze, sound corny ask eliot ugh itd swelling away! Intersect overlap arms race. Fear personally profession engineer schooling hobby, influence, = purchasing degree. Bodyedit hobbyists hobbyist groupssoft artificial datum heap, variant? Birtm, megadeyh buddy con. Depending grane myclass anlise nota. Catration cyristian, iusic funny. Sean alexanders slew search wildcard need edit replace? Useful society, matteri rightly compete. Join sign visitors signed = spotlight. Learned firstly, certain they them? Antipiracy fee allowing exposed root = mark. Batch delete, favorites pss caused surveys polls type button. Patrick = ramsey, mewelde moore saturday tcu nebraska oct, wrpr! Scores football = matchups injuries basketball baseball ice! Rupert thomsonthe william musicsoft kings. Engineer schooling hobby = influence purchasing degree global, says. Wanted mendax geek, couple = belt unstable buggy. Release browser compiler windows. ------=_NextPart_001_0009_01C75EB7.523B1BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Websters robbery seas sea violence = lawful.
Faxt ctivation gmaeyel invitarion. = Penciled brandon=20 iron man ii.
Fix, adjusting, reg simulate utility. = Wrote audits=20 retina, scanner principal consultant stake.
Pakistan india pledges current = view.
Holerdquo forcing encryption = algorithms, unaware=20 pushing hd routines.
Froze, sound corny ask eliot ugh itd = swelling away!
Intersect overlap arms = race.
Fear personally profession engineer = schooling=20 hobby, influence, purchasing degree.
Bodyedit hobbyists hobbyist groupssoft = artificial=20 datum heap, variant?
Birtm, megadeyh buddy con.
Depending grane myclass anlise nota. = Catration=20 cyristian, iusic funny.
Sean alexanders slew search wildcard = need edit replace?
Useful society, matteri rightly = compete. Join sign=20 visitors signed spotlight.
Learned firstly, certain they them? = Antipiracy fee=20 allowing exposed root mark.
Batch delete, favorites pss caused = surveys polls=20 type button. Patrick ramsey, mewelde moore saturday tcu nebraska oct, = wrpr!=20 Scores football matchups injuries basketball baseball ice!
Rupert thomsonthe william musicsoft = kings. Engineer=20 schooling hobby influence purchasing degree global, says. Wanted mendax = geek,=20 couple belt unstable buggy.
Release browser compiler = windows.
 
 
 
3D"short"
------=_NextPart_001_0009_01C75EB7.523B1BA0-- ------=_NextPart_000_0008_01C75EB7.523B1BA0 Content-Type: image/gif; name="invitaino invitalion.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c75eae$f076b3a0$c9b46852@raffaella> R0lGODlhVALoAocAAAcHAH0OAACMAIKCCAYBfYELgACLc7XMwrLTsaTV+0ASAGkrBH0lAJwtAM0u AOwWCwtGACNLCjdEAFg9DI1JAKtJBck5ANg9AAheAx5eADZuAGJaDXphCahpALlnC9pfAAB2BCh6 AEqCAG11DIeFAKqLDLV1AOt3AACoABqjBzijBWCnCHanAJuYALmoANeuDADIACmxATm1BWexA4HO AKu0ALK1BOK7AADfCRTTBDPRDGXuAnjaAKjjCLPbAt/rAAwAOS4ANT0JNGwIRoANMZ4AOsgAMdIL OAAnTiwVPDcdTV4lQHcVMpkbPrkWQOYWMwhKSB88RDJCPVc2Png4MqY7RbU5S9k2RABrQyRiNUlS TWRdMnpWAKphRLhoOdtpNgCEOS11OziGNmh1M4RxM5KBP8qETOV9MQyaTRyZPUueMmCYPIqYMZSr Q76TN+OSOAK9SxO2O0OxQ1mzQIbMQKTNSMzESOzCQgDkNy7aSkXXPGvqN3jdP6beQMbUROfqOgAA iBQIfEAEd20AiX4Ah5EBg8sAdtcAjg4ojSghfUsfh1Ytd4Ynia0ffsIahewRcwtFhB8zdERDgWM1 i4AzgaJKjLZEfNhGcQxreSxhfjNcgF5fgHJlc5tYf8Vdc91lgwN6ixuHdTF4dmqDiHRyf5uIhbty edyAig6idhWbhU2re2CTfISniJSph82ljuKhiQC7ixPLi0DKfG65gYrGjpjAjcCzcd/AjgDpihjY fETTc2zah3HscarqgszmiOzXcQwAvi0HyzUAslMNxIAAzKsAscEAy9gAwAAVsSEmuzIqwlQsxokg y5IfvrUszNgcvwBHtSNFxzg5vFVIwYlAxq5LvL84ttI/yA1kuiRUzjNfvl1ZtoNdyaRUsr1uxeRd swBxvCaJuE2ByVaCt3l6yZN4xsdyzdeCsQCRvCqivTWWylWhvYSqyKGWv7als+CayAfGsRzLuT7I yVS4yHS1yqu/t///+KmorYuGf/8GAAD/AP/1AgYI//cA9AX0///79CH5BAASpHgALAAAAABUAugC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK/GevpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp0+WI4MKHUq0qNGjSJMqXcq0qdOnUKNa/Em1qtWrWLNq3cq1q9SvYMOK HUu2rNmzaNOqPdu1rdu3cOPKnatyrd27Yenq3cu3r9+/gAMLHqwVr+HDTwkrXsy48VvEkCNLnky5 8mHHmDNr3sy5s+fPJS2LHk16KejTqF+WXs26tevXsGPLnk27tu3buHMjTs27t+/fwIMLH068uPHj yJMrX868ufPMuqNLn069+uvn2LNr3869u/fv4MOL/x9Pvrz58zStq1/Pvr1o9PDjy5/f2P3Qrfbz 698/O3BG+gAGKCBxEg1o4IEz8ceQfxHVpOCDEBaEIGYFptfgThFmONWE8VWY4EgchijiiB7K9NWI KBJIG4MQOXhbijDG+FeJMcXGk4Y45ogQYDTCpGNCMgYpZF0XfqjjkEgmiVKPqv3IpItORqkWiw5B KeWVWOpGZZUWZmmakmCq2GKXXiYV5plyPdmSmkCVqVR9bupnJZdGPjRnnEQJhhGa4rG5kp9ERrVk hKeRxKd5gNZJ0J1NMRpdoYm6hCdZZNLp14mVTgcpiIeiViRWu2XKkACkGkTqqQIMVGpBqxKEaqpO bf86aW6OKlTYZaIuBCurrwq0aqv/AOsqqsG+mmqvIcl6lz2zblQrkFmFqmhDwqq6a7Gn8mrqrr9e a222w3pLrKWdSWtipzZFmhOu00ZkbLfHeuvrtd0OexC3sFararHW8juvoZ6ZW2OzO+Zq663J/qnR s7riy6pCwrZaLbASO7ztvvOOGyxoAvsIon0MH4QfpyZ+OvBF4CZEscUIRcxyxi/DOy6pJdGsks1b 2hXynnDhtbOECCfc7sFDQwTvqBpfbK+/LYsbc7zWnmQzzlKjyhLOROvEbskijRzZz4sGDRLYA5Ed bMPfLo1s0/9uuzLTK9ncrz1U0y2A3SZRPfXdKZX/qi/GAHO9rMHOit3QjWMTXnC0JAtOrsfuJg2z vEpja3G9bLctEN51W+2S3nd3/mre9OZL+d418526SVufLDSoJnMce1VBmR246w4ZG26rdmvONLX4 vl3x7auTXjXeVaveEugpa96t8cWjNLzlf8eq+H+GL9jb7FTVfr1Btq9Nfb7RRy/39NXfCy7NOE99 fN/Ktz+69Mqr7DTy+COv++6/Yur4R16zE494472iQcuAaHNZseKmvJP4ToFMw1zZrhY6vqFOf6qr W/nk168OTvBmDZTYA7kVGqjYjns/UVdbVNimx0mqcbg73PcaRizerU50vatc5nzHL/zJb34gxKDx /y6YOh1K7H3lY9YO53VCFLYwcYwb04yc+CcMJWaGYUMg2rT1wb6Rjm/9etvvPAi+/OFQiAxkoOdW JsGNwQ96ORwh0LTIMzpepDAByKNB9DjHS1ExUALUGhT/pz07hgt4SISjEtUHM7VdzlhfPNUbFXlD zzFwh34LIRH/Jr4GQu51MfTIrfJISoLwsWykzONJVPmYP6aEhYu8jyG7GEoajpFiSQTh0nYJseAB 7ILyg8kZcykziKVxiJ78oQY/OchaciSAAjllNAOwOVbaw5rWNAkrs5nNdLlyUFIkZAGZWUhxQkyH MPui9EhntOnxkoLILN4mPRnEEopxbkIE3TFv2P/EcDqzcNFKJTWnKVBqpqSb2wwAShJ6UIWWBJsO Zd03HThRiUoGi9+aWOkmCb+Mqq2dwaSfMDNIUrpFsmrAm+Aw9SlPS2J0Iv0MJOymacpUotKh3bxm SxCK04Y+NKKhkSYfpUm8JvmTnFfECVQsmMz4yYuTwSsdE0fqw6ZStXiNtNywOJo/Yro0ijL958Ky V1CarjKiENUmWoF6TbaedaEKJeo/hjrQm761reAMK1J15pUxabBzW+ThGKNWyXhCMoghTaT9OqhO Rb4rdV/N3kJi6kKq1JWmcxXo5uCqEp7+lLN4/exdY4nZgegxpwx1oFAHSlTK8lWQlXWs7t4lWI// TjWRSARmBUUKP2RpNIsc/atT1ynZrO31mRZqV0HpCtqcgtanb0WtQjNr2stSd7NnXW5b98ha64ZW tN20kWLst7bmYctV8EwsJeEYTPbdjYy7JOJ66We1ZVoFljA8bkI0W9rq7pStnv3uSpyL15pe18Ch la5FDVzdzD43vKeU62T6WhEENs+98ezqOtWbyyKOMJOGsm9VIStJu0WWdhUtISj1q5BSMmStPwWw W0crWrXWeMEEdTF1Cyrgz2ZWxwwuKjfjGuHLSpi//QULg/iCYZqIGIi/VR8lJelees73KvjN7wsj stzuCjTGBNZmdElJY+iqtSB01axLEmpkaspV/494da41D0LU0yI5xxJuFI8udMe9VG94wlXjbnkr Yp9kuWsv/bFNq1vKMoeXuj1e5UHbOuQWW7fLOHXri81q4wBf983WRfOlQ229KR5VdoiEHkvnd9gS gzW2T2wmi+kcajs3OtIJnm6Dg7zZtDaUu3M9cJh7XOfulvG/D40lXXdd2mLnZc+n7l5RsTzRx27Q yiiO9pq0vOWHAJnRNhVwapct6mMTm639BbVPt/lTS4u6uZrmdZGDfGep5Kyc1B5Tn/0MTRnOkiJN xHRNZ2zjQZH705nu7CuZjefU3rjd5Z43wR/u7APv9855/pIftW3oFCsRtrDumcfHKdYXL/rAn/+V s0PdPcdU3jXNNs24xVGuxNVyF97ZJXWSK65oOG/bKNDWa7aF3u1n55voP1+xUTWy7NE6HOHAxm5n 471zY8/86rye+Y2lW9d5D/ziaPam0ukCS9u51n8l72Pa923O/Q58tWRmCUMZvuO65lrhEOduvYut Y1CbO8AS9breyUz3ufYb33wp+7+nnfT2JPrQHeExjbe5kKZHetxdLytBsZ7xk1v84ZEuN93VGvc0 efzwk72JNrSx9JADsnUbl3XrG8J3z8ckoaIv7ZqJrGu/Qz3JCCG1XMELY9XWus3PBfOwe6L4V/vb JquP/kmiH32BrB7xs3fNCsfeeNovGslkVvn/wk0+zeTP+eKa9/1Qs15GBS/J5lqndNwlX9wDxt71 LaE+602if20M5Pr/AIAB6H8DWBKrl33VsX1IF2vkx36mRXwQCHzDBxOUl3twR2vpd3zgVmavdGTH t24Td1+nV3+LIxP6Z4AnSFEDaH0EuIIsuH8HiIIyaA8AKIAEI3VD5xCah2flx4EPRWvNlnDJp2KV 52Y8Z2ucp13nll25x2zD9mUkKDJBh38oEYMpYYX8x4JaWDBYyH/754Vb6II1SIA2eINC4XsO5n64 54Di910RFnUSEXNtxnAExnvfl3k3B1cuJ3+oZ3990XxeqBLVV4ZhaH2C+IULR4iKSIYtOIbW//d/ LWiGhFNkBVdmM+eBQ5h3BgZ/aChq34ZZ4lZ8Pxh8rNWD8jdjy4c4HKeKbVeCMSF9VUh9KBiJLlgQ 1zeD04eIhFiLCLGIBuGItah/kJghOIZoA7ZWwBd/QzZ1TZiMPZd5nxhN5oZs20VvXUeNqch8I9iK 2EMTWJiCKFiIAjiGuoiIgViIAziOtPiC1PeL6+iL6WiD8PgoN7EhbVdkRNZQ2ZRupLhccGiB3RWK D6eDrJVzbJaNIEeF62KMOgGOoSGPjAiJuNiFB9iO6BiGECmG63iRtriR7ziMGSkbyqFKchhxGlh4 l6iBU1dwB3dwOCh3pTdTC6iN3McS4NiFNP/okRG5KN/4hTEIjL5YkT55iMxShtcHjO64ELsojwSB lPOIFve2FLb2iXb2j5jIgaq0ay0pilCogDOpinqFfS4Biy/RiIxIiziJk7mojsNYgFaYlqwHlO/o f0YpjLzYlBuJl3oZjHupkUZ3f89HYf1ohLUnTVs3Y8HGflNJessYhdMogqvIE/0Hg/1XlBaZEOYo lD15ELtoiG/pk5RpkUFplncZj2hJmiHZmXh5maZpb1MYmHpiaYvpdBGVbnMokGYmkwqpVNtogpXp hbDYlheZk7h4hacZj3hpnDZJl6QZjKg5l7zImiDZnFp4lNUHidLpmoAplsLhct8Gf4bCU3v/2Id+ CJlfOX6pZ4BJeZN5CYyB+J4OxJZJGYvE+ZlJ2YuXaZcsGIgUuZPYyZmNKI7+aUKmdp6txHjmCYSm eJiCuZv1OHIRcZ2r2Y4S6pcaSZTjV5fumIvK2ZEWCpfLOYNCmYsYSZ1PKZwEup3pqaLG9aCriJBW FJkxaqAq+BCRqJ/IiZ86WoAiSpkAKoXEuZawGJJ6SZ+fGaQcuhI3uoXqSJaz+I1o94cyeqA0ip6A mIOwKW1TWqMO0X9KeaP+qZooOqF7SY6yqJaLpKESUo7KmaQ9+ZRj6KbvKaZm8prcaXpbOqNXWnRZ mkIQChHyiaJ5uaMlypEeOkf92aP3eWyJ/9qmSHqOhbqahyiL4aidLFqeerGnuvmnfeqnVUqEXTqg GsmcL2iL/xehgSqX5vik0jem+gmi+ZeZq+qcAEqpxVmpDNkkUdmimdqbUvqSnMFCFTGZ7EikTPqc qQmoZHmkOSmmhAicSRqt8AlOaho2DlmFJBesvpqgd+oY9ligDkpaDOGl7misi4qOTsmcqXmtRtqc 8hmrSkqZt5qT5wqA08qqrMdt0LGtWNqtjGEWZGM769qXmLmTznqcZep/MjiiuGiqOvqZToqm0vqQ YPqIa5qCvymuHaEsnToXmkp2lhqbylqsEwqd0TmowmmdCnGL9/qT+SqXYUifxsmwDDuvjv+qRCDa hdmqGR/rqZ+6q2/yeI+JgL1YmtZZoelasAI6rmaJr/RJsH7JrPW5qjbLrC47p2iascXYjUcHrAnZ sXj6s3bKFDHlleUqoeZKpEi5nhDJrkhKnfPZsqEptc1KtVkLmhMJmlTLp/6qp32bV+FKnq6orSnK jZTRmWuLrm2pjsDJnkxriPc6sY16tY/arHXrpDJrdo6pdkSLqXzrtbfCsWQrtAzpFKqZnTwKn3N7 muSaussZsXtrgI4qtTU7p5qLQK8Htrn7t1u7ouERpZ1bpy4KefWaubF4qEgZixkrsfxJtzfLqhO7 dsAlvRWWaGZTHsAbvEcRQLzJca07phL/KaRs2q62yrw9qreYa76767uzVkeGy7naO7Tdkb2fG7TO x7vdZxE2qLx2K6uPCquUO5kYKnY/u7P1y775i8DzG7LtWxSCC6SC070LeLfzOrl4a7k02KP8Z72k W8AM7B0eUpMKIyj3q8AJzKsnFKI326iqq7fX28HhqmQB47m3+77T28AOXMIofMI0/EQSjHTfWLn/ G7sMiL8au7EwXGqXCsHUC7pFbMJPrHGbCsUj7MEAxxdue8CDG7/f2sQyDK66C7hhLMZGfMRS3LVj 3Ls7HMUAZcZlvHhnt8ZVPDhgXMacyrVqbL9TTMXr28NzDEA/nKd5DL9ajMdcPBb9dsi0/2TDCNrH o/HA8svDWyzJhqwcBkzJlLK5XZx416HJi6zITvzHSEwYHQPK9Ouzster2ufJoezIk4zJbCe6o7t4 H6ylIhwXsOEWMXzHgIwchAyyPsPKMDW2j4xqVnzLvhHLOlwWwtyzHdfJMyzIbjxWvowlkLzJeyFe 0XzMqSwcmcwVyPy1o7zElmHMu5yrxjFhBCxKzcyvqMwa5pzGg1zJYiKS8czO5FwZQDtH4wyqvVzN 7rHP9OyxW3POkRzHUGnJR8Klr5XPiCzMNdzQx/EjZ7fOcozLhnHNN2zKCE3NAI0jNcwcsNevfGyl 8uzPevbRGhLSOIzPtizR3GrHvJzSE/9N0S/F0hZNhaX8zjItzaccHE6C07C80bTcyGz80Ht80Sbd 04WbzjYNxzctNrqsxGhc0mRs1QxN0zWdI0I91J/M05dcyFe8zK981Actyv2c1a38G0/NyGt91Uq9 kOic021c1Vg9z2e91Gn9HX7yIhxsDwDgxRo91s1BvCc9ze5b01Bd1MG82FwDAIGbxHdNk2Gt1nFt 2X7syont1HMt1srs2dgM2l+NEoGN13NU2jIBAKjt1YSdGp3N2kat18il0v/sxYa916L91phd1iuh 2qp9Er4N2MAtEJD9D8U9264tSxwt2ZMty8ht2zN917EN15672tTN2yrx28Bt3Sp43MX/DdnHbdzE LbafkdfP3NyVzdb6atabvdxJjancXaPendkpgdqBHdwmUdqBPd78Hd4DMd/i3d/jnd/xncxs0dKt XRzpLdt1jeDTLdcGbSn2zRIFDtirrdoBjuEa3t/fzd8BThCQnd8lMeHCXeLAzbNA16ANXs/dzN6f ndsPHshGrHi+/dv3bd3gfRAd/uE7vuPiHeIlTuInLuImbt/xXeFm+9MvTd8GHs67PdDDO9rnHeFv nN0jrt1E6N0+7uP/bRDFHeQjHuZirt9ibuJEPuZnjuUWjuQyntFNtNUtjtbPTbhjo+MJTuBCbuT+ zeF9lOf9beWkTeRkXuRlft9XXt9r/67nhE7XxfzkTMzitW3Kzhy2y6LmYW7j+d3lPP7niL7oQ77o 911U3E3ig07qaW7mZ+4SqJ3L4hznSe7S0E3edawRez42+G3m+L3hBaHhOW7cpz7oFF7oWa7pGR7i oy7owg7maB7sDA7iFzXV7kzZrt7sUA4nTlHrDWHpwo3pmb7pHv7dqK7swD7hZI7hdu7tgQ7qZU7a aq7tnYvtDAHvVJ3N7T3lkS7p0U7ptH7uonThFd7rIA7eAH/qyV7gpT7ixN7r5n7kyZ7uym7hCC3v CyHxuE3Q0gzWLw7bky5yTFHrFE/cEI/j2r3fzv7hzh7uB+/peY7w597jqS7kvd3wzP8NEb6tx79K 5bWs8fmO0U/x8Saf6Prt7rzu7R3O8A5/7OKe8Erv6zE/7pbu72yu2fpMzExu2kRNug6+8RxP89fO 9E9/64sE4CYP8uKO7Bce7iU+9hnO6SqP7DG/7Yze6A599S4u5X8M7XO+Gezy9VeO5YYu5j/f8Eif 8kEO8Obu5Zsz+GNe8+CO520u9zeP85PNJM132ALt5TXfFMC++O1e8ASP8oDu6d3e45pu7J8/5mNP +sCK5Kw+65dt9XYv9XQvyv1E5x/x3T5fJEFv8A+/8ure6dvu+yom9nue8qb+7Ye/64yS+42y82Ap +a+P0pPv/CjO9SCR/A6x++6e7pv/v+xr/unlDvMiTtz+Hd7H/fmjLuDkn+NAzthrL7yCEfWIbd7X /eju7dYxrt4eUePYT+vtDxD2BNoDUBDAQIMFBSokeHDgQ4QLIUYkCNEhxYr/Cv7jyBFAR5AfJY68 WFFgx48oN4LkONElRJYxZc6kGXNlTZwxX+7k2dPnz5caPeb8B/QhUZZGByIFqfQk05ZOnUKlKVUp 1ZBYa968mdMiw68uGY5NuNAh2JcX0SJMiVKo26EmTaqNqLKtxoQdpWrl29erVcCBeWKVWzIo1b2I pyoW7JOxYL8580LtGnllw4dl2YJVuHYtW7Oh1Z41vHRoVpZo6Y7MiPeuwayJI8+O/9zYtm3CTvN+ 7HpTNtPfSG/3zG1U5vCfkj3eJVp5ZkODaUeD5nxwOmaL0kNjV7m8qlzWEVe+Xn55MW30WpGv72n4 MVC78UMWPiv+KdTgRNm7LG48/X+snJPMrOgyq8660rCrbrvPEkpQIZtSGi8l0LDj7y3YZEowu6MA 9PCv/ULcSbmmrsLLLa42ImlFmNpy8TSh8gNRRHv6g+9DvSbCkSoVxSrQQQItHIvBB+urkCzTXKOp R8yQ5K683u46b0cqo6LRqg1HxIk5n9xTUkMKjeyMNQlTq2q1uZ7E78oa30uuStyqzFE7HxXUbEE7 SSoyQ+9O9FMjIifqjM8v/azQwP+SPGQOTjYbXRSnLr9K7cW4jOTQOptOc/FQC4+iFEMp2bTxTSpF lfO7OlNF8ro8G+rz0Y0KbHWskAitVTbnBPzvUeAaRS5BpDY1sVbeJrNUzJHe0tAt8JpVy0zUmkLz WKtGdYzRK930tcsNnWSou1clJG07A09K0VhZ/dNK11Pn3DbE2dJC6M8+hRIpMzLrwjDTtsjFVyJl YYTRMILFwmg0h6wlDlsaFdYyqSkV/nbScK100s6KKS4qYirZ7etdda0crF1ioSw237ms4/DfGNP8 6qJo4YpxtZJoPvDCNYfdsVGHHxYuzl0pnHXcNl2rLC8ZSUYP5Dd5VRpaaIvd+N//wg5G2VJO6dI0 07eotjrI8KAruledceRZ24VzvvHpEgUl7TUHDeWY7XiZTjtgus08ukyMKBpy5Wlbqo+zJLl+kUWX EZYOU7RHLtVUtdcmO2T97O5wps+uzXtpy33+OdkdpYbbW7+rFpRMrpX9VFyodyoNQUStbtzzD8+O nNTJJf+c8ql5v13HzTnv/LDccXd6WalrFblJlU2n2W+BU190dZnL3Lr3zag+/rmya4e8eM3Bv3t3 3YM33+zhiRefdsrkK8/v5l3+F9mFBh7q3CWhrr76gwm/b332/cd2AFQf+XBnwPChDya/893T0lfA ynkNZ8EqU5TaJj/6YbBqUbve/740NT2nWQ97YGNNzyDooe8hcHwRbGBNkibAuZ3vYw8E3lYg1r3t /UlXP4of1kqHOLhQSoRB7KAIjaiXLFnKhBNUoIiWWEMCMpGF5UNhDF3YmMfR8HIkeuGSYoUuFzXP h4lDHMyIODDyqM5+qLFev1Amtnkx0HE7S+GM4DNEVLUwj1QEUBe5170RatGJmPtjpMYWrP3Va2PT +uEYBRW95BlOZmsUoiI9GMYc2sSKeyzgAFUYQBdmSYp2PKD3AAmpTUZRkKNEpcFYuayScVCMjQyb 6eYSIVji0WNHjBYvT5TJG+qxkIJ84gLpNczkAHN5paziKa/ozPQATT0rzF8gqf8ZPXDZ8F6OhF3V qAWdXp4xdftjzqd6iT8e+VGTq/zfJ0HZOvlxKEDPU43HaKNOnaTynnN7Fyld104eUc8jzTqdLV15 EDVWcHqJ9OA4t8abSSnzOEqR6DLb48kpMrOVfSNXwGAluE6lK1ZB1OXsTrhRPsIQmshkJ1PKydCW kdGgPKlPNjn4UEsytJKxxKUc35kpdgLUn8SRaH4+ClKOxm2kRUzkTvEZzJRGU5/5BGQ/t3S/cmbo a87jas0IsqXJxEycaVxdGsszSXe+kpM+EuV6iukp/LTVmL1CULqSZdZwNlSEXGUR3lCqUZUKc6Ir HewWMwpNHr7xdRXpYZIgetb/rBwPr37V6znNmVa1FpaYJp0gVz6ZsKJ280hLmSxMj+qsH9Zop5eU q2FNKViqwhaqgCHZPzUInoShyF4oCiMbJak/UPEKj5iFInFB9tY4Kk9jOF2aaP3FFkp2EJuneSPL XtpBvrqMslIlbGyjylKM0rGgX1WjR/m121dF97p+Xa8q52pcq/r0pJh7rHRZty+npalBP7pai8aq kvHK07xQK1gZV9vbok51tgk87AM1y+DZHFhgR+0NmKhnzwdD+K8O5qzbwmIaDN90wK+hjiiJ9qA2 tRGtXSVYe1GTWu1F6LG20k9rCwffGzc4fWzDovSii9Y1us+9rh3qjju8svbw/5KsFUVcPBc7Il/G xpafKW+uiuJVVyqXu0ZhsoIvuFkZKu1FZaUxjoW6YQ7LV5pXFWdDAUXRboVnoWeqrr6EKFyU9DfF QFZScTM8RzMfUsfDCzOaf9qXEC/4ms9cJXJpK6chigTLQPFlpC8FrCjrNMhBzpAbs6XmzTjaV4UO bHi/DNi1pnnIgDlqeioYyr5hrctoYmxm9DbdTHNayNZ065FzXGRCk/pU820mscFrZFCz+szVBC5Y I7pIBqUlZpZG1IY2PdzrUZjP91ppZv8MaGB3TtjDjmF8jx3sZNsW3ADKaqd9M7/SMXWdsZbzuny7 bZu667v77K6i0T1u8co23P/vFTV7Cp49OS87aHAjFopRltfD3ba4ZOVLJPONl6f6JeP6piHAGbZv j68a1eemqV0dhNAzXpYyhGL5QPn6LB9T92taq2yz3YztrWycLzrndecqGnKRC/p8azbhwatNoNyq nLLmDOGu3yzxsxB4YK40HcSbCuRipQiXPBe10VsIyp8DneMaDp7dsjic0ki9vAMWq3q/nMHkVlpw dPFf/dTO3vT+mL02JnIfvTx2gwcI0Xy2997q1m+liTvon2Y2LO9eWk87z0ttTk1qV0NS/c157crD 5NMFPkPEA77XIVd653vqp9VadNGbC+qhT32b3O6q8ftL+Moanm/APei/kNT/+9LdJy9vH/7z3kVO mMMe0ZFW2M1Tf17Yxt166K97u82hV1gtBvyk41tki01U5mMuUJZHKXPXPD7xyb5lkNfGzxHG6nIJ bMRaHizbxyR39Aepccjk8tkla9JWFW6yRbIrjGg7nGM7uxidF/u72fsYOeE6X/u15sgqALwvp9Ie +cupKuMt4bG//eCx/OOXKYs3FVsxjqq3m5uk4VK64Jq39EOPMqut+As+9Rs94BIX5ZMwaGs+k3g8 tNI8JYseDry/gFslCKm5wykw59M+edu8FJQyihI21xs04lGmsDq512MPhqMvudMUGKOI+ds8TeM9 AlOs8QtC6Su1kcsbofkm/61pr6a7N6Y7QNGLQptDvzQ0vzMEq5arvC4UDHbptC+MGoS7Gh1yvMoq PZ0ioZcxwzucweFLNWM7rOzLQOkyQBk7F257RHsLuq4rlfjhlIPyHIFqO9aKJ9sTqzuzOYp7KKHZ KlpjxPXzu9DbOVULQyO8xIibxfp7RAckIBRzOLhiRclKRIJ6nshaqAozqx9cozKiDljMww1sQdDT xFOpL8g6K74rQlLjOZ57Qz6EPR2xRiW0F3M6HZWhu1bTpTfcwq4RKdWQCr4ztyaSRlrUxY4Dk4wr vwf8v2+jwwUEEt0oG9iIm/1rO9yqs+w4R8LrPTDsGtSCDjPqucCIx0c7O/96nCZ7fMbzyxtuVECM LEGKtIjb0z6Vsw8J2ow4AyiIqq/x+D7sEUCzYLMrBMdqschGxL+MtByxi8abnMNIHDyJ/Iknu49I Gp1K+hRXtK1JuzE8q6Zk7JYxQTn5Ckl4BIuP68l65EWNxMqr3Mh+/MlNDMoSXBvrwzWW5J+XG69X LJpI86K8cjkLtLV9NKQPHEKunEuvA7NprMivlMGZ9MespCl4NBfxsymVA8jbwrLmi8hRPK9pu7I9 Ecl0o5HJs0uvdMSL3Eq/FD0YBMu/9MwDbEmSG0vBtLvTu8WEurKTBEYYq7SmLEnNGESpDBZTg6oG 9EiZ9MlYZDTN5Ec85ED/3rxLyggbqqSaQqmX7VGyLqS71bycOVtF1eESlKylhfQ34NPF28ROvJzM 6MvLUcPM3USk4KQ0JJNMGTOatRtB1rS8Q4GdTcO134LL6HhFxrCxnRy48FzA8Vy9P3IumNTLQPs3 Q6PG0YyTlzoavCsvmcKXlLyUHrSkyQqVYkTJ3FQ9wNzFa+lIgpM5XZQVD0W4v3EkIQzQ3oRG4QsR BKxQ0ZyZAKuz19FGUsw0+EM6JBS6ASUoKKwjryjDifRNqHLHgmJDkzTFmuTOEm1BduIT00vN6YO2 uBTRd1QtysM2gYIjKxWbTiQkB9LRG33IBvXRSpEIz3C4xSzPxCST7jPS/yMV0I8UCy07TkoElSYr zZkjL2YDv6iJTC/cThc8UXiZy7FcixidlNiZznLJrqSCn5pRTHO5Nt1cU8Xry+LTwpTjwkthz+da oPWiwDuNCne8PD4tNC7dz9FrSrh0lrIQUsVikbUUkk4RQw+SOCKF1D9V08Djmjot1GZsDRdzqJ3S U9Ax0udjPJELyQCByABbyv5BTfkkzj3N03xCwgyyGRGlVRP9zYbxU9Sqpw7BwcsaLmdF0ywV1VEt 0JOkup/rFAVRN68pLTV6UnyRN+sJRTQdRPqw1pw0u858GQzEG2910g/d0C7NT7qpze+wz/GkvoEa U1WhJdP0vTwLVH3pvf9t0rMXXdRWxVfQtFA2FTYZBbD+oTlhzdHBzMzF0Mcrci6I7CYdjDtOYxKC Qh0lzMSW1cHpKM419c4OBFSBdTXZ5IxxDbOzUaZDLVobJZEdXVTsGyOYq7n5WBHP+B9T/Ru1dBsx ik3yhFSdvdXF6zHwjMmR3cZyfQ7E5Kg2K8C/UFn+QtQ4UsFmZSzd+6DzOtcJvU6czdqg4lliJdHh 4Nu+49jNbBe0u1AefSRT9b4Bs1rFXVdWnbFtQ0i5wDzMwVRWAVb85E8n3Fsp1Fdb1dhenMdarUPV TJVudSmIhRhGlVgv1Tu+EY9uec+pk1Uy9KGg3dz/5Mq81dtGg8SevU//g2WpsgVbEWvIyV3Pdq29 t0TBM0qTN12nVmWkK00uTgzVDNvaSe3c3U08osPJEd1cPxPHZqM40mSrl0GLCTvfu+Mpee2d54Xc iJzeYsvO7PVbAL1PWezetB1fMPU94arbJkNYa4zQe8Mmt6WfllVEuQxb+5VUprHeSCVXsMzd6UVZ QioYMk1WgJkubVLex0xc/7PbIFEZ6l1gbOXcrp1fod0kLXK0inOpJBoUYL2rcWrLkfwts2rNGJxP ft1HEubJncXeFSZZrazL16JT050nejJeDKrg6kHQs/2cT6zZF/1b3t3YHmZgKrZirRVikz0ubYVA h6KgQdHVxDwWAoYp/zgcyBmOi5h1HQH00Nq94hEuthLlYtwt14tsH4Udof1SnGZkXdhtzFtLCujF 2GEBps+V40T23iC048u0zr61QyteubcxGJGKv6N84vU949i1ZHQ12v29PuGUY8AN3DbtzWEd4mwl ZfAJ2GIELdgFwxEE5JkZyueFyThmZTOT3zp2ZMyF5NtIZVPeywQ+TN/aoQe9H0+l3FpT3KjT0hIe Zl0Wy97ltyMV5i7GX/Pp5ZhLULnNn3DVL/8JnCb1N2ub5lyW5K3E5jteZQh252gOZR5BY9X5YITU YTulKwJl5UW+XHn0CnZ+5M8MZrHV3Gn+Jrr9z9lk5GBE50BjYQnmZ/+P/F0PNOh9vVYd8+PyZeF5 1mUN5WbLJNiBrWYsDgxfpkGHpmaTnmMXpGA6budrtkmBflSSjmevfefQTemtrWJpluh81WaVnulT FuqglueNk2de/mGd/toGXmp/BmOe3t6RpmIfxuiBFmlgxmruPdqtzmmnTuqe/uqSNuqxHWuurmqr LmWtpmmqtuZsBmqxHrptsd+PhmtzbesvTmu1xuuSBmskLeu4xum1JuWJBuysrmmm1uuiRmrB1szA pmuU9l0FpGib5uuuJmrK1t6cfeydrMW7XrS6VuqH7sqb3msiluvN5mygW+enLtITfutRfm2QK20Z iug8Vm3N9lzcBGL/mI5t+u1t3y7ie8RtndbtjXRsllbnyG7tsy7YliLu4jZuxU5hU+5nUr1e+G1s z4ZuwpbuC3Vq675uglZg6kZh7u5u7w5r5/5lFfJr7B7tgjbv877i9J5kEg7u+7XryoZqjozo+Vbk +lZv8P5n015p7gxorq3e//bpALfsBc/rB4bv8tbvr75tgGvwwX5wAsptBy9wxg7p5ebs8O5vDOdv DQ/M8Y5qPhpxt/Zq1XZt+i5xEz9xB+ZL0kbw98btzOZw0Z5q2qbxxO5Y3UXsl05wHTdsHjdy5mZx IPdvhv5umVbyxxZyDHVx8U5xIG/x7fZxJ/dwGH/xLs9vK7/yH89y/2LecjIv84FW7t1m8PotcilP cwM3cwiP8CVvc55W5/NuPffO8Sf/cjofajRX8TkPdMiWbzGHMPa+7EVPad/m8yEnatTe8W1+7iif btLGdDcH7uGWbfwuuzev8kFHayhPciJ39MK2dE+X9PjeN1YHcSondfs29Ivm9FE3aybfUu288kyP dS1vdFpfb9ju9N9+9Qn/dEbvcDmPczYX8GC/dMCEdN429mOndjjfdVzP8HR+9kr/aWL/c0Dv4VxP dnj+2j6fdW6Hdi3+u3BfdhsHcGwXbhOW7HhPd3l3q9AWakr3uHEnd50Mchnpd3tH8W9n7hrX9pMu dVj/d/RW9oFXd/+Gz+5ir/eK3mfQvfU6b+qHbxd+6PiOfwiPD3l++E7yBveIr3gLX/iTv/bTPuyU f/iQF4iPH4iZl3maH3mIqPl2J/QZd/nu7HV0v3iM9/cg3vg+Enme0HmZx/mbt3mQZ/qlP4qOl3iT D/Nmd/ZEH3qi13ijPzultwedn/mvj/qJUHqxZ4mpB4m0b4mxX/fUFnpNV/l5v3dfJ3iH5+6XEHmP L3uoJ3uyH/uZj4m154ipN/u+b3sIotVzR3iIn3uWX3kc33mc/njDz/u+B/uwv/ya/4e0H/yO6Pya r/yvP/zL9/Yef3ysv3rHz3pkq3bGv8+95/umz3mcD/3Sx3yXCPn/z+cHtPd4tq/92499sdd7ytd8 qNd5zuf9iY97Ca9tq1d9rnd+Ly404/d73B99po/52cd97hd85e/92Of+689+7feJ4ad9zO99wW8K xJdqNLR21q/7jF99UC/3bAd02g9/zC//vz/+2gcIewIH8uNHsCC/fwr/FVzYsKHCgRIRIhRY0KJB excxaszYUSLIkAohQnSYsCLHkBtDshS58CXMmDJnRmxpkybOnDp12uzp8ydQgTuHwgxq9OhNokqX FkWKlOlOp1KBbly58uPBlBhHJjRJkmLWg1d9XrRq0CxKhl2jmgVZlaJHtx6hLnVKV6lQolP38m3J tC9glncH5wzs/5Mwz5+FDZONG1ZoSbVq16rV2vFtyqsog5Y16HVtyYeO5T7G+hhx4qOoFzNu7Xrg 39d9V9P+JxtkbZm3e9YWzDVmZNto4Yod29n08YlxdYq2LdYyZpsUc8uEO9ol9Ze7t8/Gy91u9sHf w2vfTn615dJarbdVSbzj55fBSYcdi1Wz5/Ps9yM8X/M7gEbFFiBQ/kE1nn/cDcgbTgDaZ9pj+x1U HWgnxbUZhCxZl5V//PFnIIEhHlaXiHsZOBOC56U4VIkOXmdchZP1x5V7ymWokY0SGegheyC22NMH QS702oI/dqeiggkm6Z2RTdrjEIUwXZhRdPbhB1+HPFqnpJO4Ef8VpD1gBlVkgU0ZeaJzt/loHold wkaYazFFSKVHjlVJ5Y5awsWlm3kx+ROYsQU56Ih/qokmi0/xeaihXZLpG5o9bYjRjPrpOd2ijuo0 KKGq7SRkmgNxKiqnCoEKKopLIkqbn+StmGifrUalaGqQouelpZcGl12sQqFaq01iDspkpyGJCdOp H5g6apgfCCSmYatKeyubjWpqLYPUZTvtTLpW6mqvw7IIrWKbKrusRMw+G+g/Qv667JDpOtvsuvTa Sy523HIr4H+7Perkv9vyemR43u6qba9PDgUmvry9ixOn8xorMaruntuuskLS23DD9d4rMbwYN8jv mgmTrFfCASf/heTJdLm2ZabXogyos4IWuy60wz4ssqkLJRtyTRFP/KbP5/4c9LzCSkw0uCa3PGuv KvsVc6GRtoaYyQoBAACsT8sEKkvMRrxsxkWHfDSyRsvrMblkz4Tqx2yDjLG4PIvntNesxSq1reGB 13Sfcqac09blbT1mm0DObXay4lacsdGRewzS2Gbz/KvcQzf7UqlAez4y3ojPvHfiogNuut8h5lYi 31sD8GbhO7ku0ewCHS7r1xenfTbkkysdt72UO1vs7x8XvTPdNodedddu8p1v6p6yzKjeyyuMrcAy uc61c7fbXvv22y8k/j+xf6r72sCTuv69mWted8SRI1+9UR23//i86qWXOT3qA1fbfNZgEj7d0Ioo r/teSLaXF/MVLnYDdCD3zBcvxbWkePgqXtza9bkNjm479gMM/ghErb75L2+9URUAmUcTEZoJgfbw no5Kp8DwfW983HtJA28IQa1FkGuHux0NnUIuCyZtbpU7nu6wZ70YKvFH+mJVAaPnL/2Vq4MrK1mr JJiqF4bvgFwkX/l82MMwhlGM2uvh64B4QDVysY1fBAkMKSgqzo1tfsBaoglDtbwnhpBpUqReClV4 R0FSkS+Cc2ECydfFHZKxkYzMoRvh6MUgsrGNP1wjJl14vroFEo+elA0fCSi904GykNkbJCFJGSce zuSRZnSlC/8r6b04DiSO4MukJc3IQy267JO+nGIoyzPKP5ayiSRE5SmDOS1esjKMCLxkLHEpy0nS MpIKY+ADfdjHX/5IFar4nzL1aEjUvApqedziOfdVRVEyxkzVdCMboQlPadLzesxkphW5uTxv8nMg 3vRnFJWJQnMCkqD7y2cqnygihLGkmtPMZSxxmM1mNhKZ+nQTP/8pkYz2EyQa/eg37aGKcAoTmAht pymv2EmVClRmWKSdF18YUVbmcJf4HNk7L9oljgokoxsNqUY9GtLrKcSbRR3pP4xqVKpdLaWB2SZR Vzo1korTpcHElU2xeVOJTvAoOdXpd4Iq1J4CFaj+RGpS0br/kKXGZKlu5WdVmVjSglo0WsaEnkHX Gc4AMrScTkWkVL4KVpb49Kc8tYlYYcPWl7x1rWtV61G7KtKyknWorAOdSaWK17oeM5R8VWVnXxoY wQ4WKIc97GTJStih0mSxjIVsZNMaEZCGJLFn7ehkLRs1WEH1r5v17OD4d1DMYnWEtyFtaXtC29Qy V6SPbStsoSsT26pWrMv9aUtsW9iB9rV/nC1uS3crXL3mNbnmhSlgXBtbtjYWJmzNrm7PCt/toha7 q63tN3Hr3dUF9LvgBa54QZtM4g53heeNFXIBizudqFe2Dk6rfO07X/hSWLWpta5ZI6zdskYXisMs 74D19Vli/5LXv3Kl6kkT1sWpxBEnWx1KfKtr2etGuML3vTFzr7tcB6u3wZr9bS+BLOLgCpilJvZj CQd8YKMkmHA3FKDrbNhMpFA3t7it70YRG+Ma55iyT2IvWjnar7tNFcXjbZJoE4rO/Z5wyaON6VQq Krsu2jDK3cOlTK1plCoHlbYYtjB+ecPRMGdUsgU281UDTGI1s5PNHnazUxZJzZ7QEir31CHXvkhJ ec6zlnCm8pb77GVRW9i9HTZ0iRHNRyIvOsRrPjR/uYkooLzTxU+WKKZ5+T0FRjKeacTzQxUMavvq mNCPhas4q7xgVSuU1d2FNYFT3WZIn3iuRDqjTuzsSO5BVP/Tn07kMyctz1nWM5pOGTShkd0vaDN7 WiNOsrQN/OFnU7vavu1vTHhJ7k7vm9/flmS4Pd3tfley071td6IVDe94N5rdxq23vc9MsJbQsuCe hmEQ9UxpasYUmg+t85O1+DeEh3eVUEuzqxvOaKxBPLR7LVHF8Xzxjtvy39akuRfJWNMyxm7kJP+5 z+F95GVHe+VkbnnEV/3LmAub08F2CZ25um6H/xzFQae3yVNc5oW33Mx0LXItwd3pbj8JjPikdc6r XvWrxzqzIDZy25Ee1ZKj+dUBqjnIpdxItkNZ7QBOJ8vB+fatc73eXnf2vU3UylsnOOl3ebHfDzTv uBdT6y7/f3jXrY54+sG98nxHFOT1lY98MGX0ox+I6VPveHJyl/NGP7rcD6/woYOwr5FHeOrzIZHT s4T0Chn9730feLfTHuXUlj3p7kow11f+9u4OiuljEn2ZAP8f1a++ypuq/Nf/eMmanz3zUer88VOe 4QtJPfWFDxPe2+P0ude94mH/1MSf9/vJt3ztJf7b5pN/6uani+qFBPuBBPvxngHCH9FhHvf5X+ZR 1eYVnfaB3TgdUgQiX8bBkPHtXgBqYEtg3/UJn/rRXwLaXQOS1APKG/GVH/ip3d8wkpwNSOMBRe6t Xwie3wymH6otoNz91985jwhKRQbuUfYtnwx92+3QBT5J/1Dt7BrOyRzczQTwYZ/11eAEDSAHjuAQ ThXxZd3LscnkoeDXTVsJzpokZRwWUhSJvNMsmdu+hR4A6t4AWqGOTF/w1WEOplwLORoJ4qG0+JUK ip8E7iDgLUi+3ZqlcZum9Rqc5ZQaNZMWOVAfod9LSKEHIqAGWmF3HZwDtp4YXpv+CaJdhdJW9RsT ituvCRxs3JQr1RnITdr/2aAltp/poR78UWHCUd3zCV7hhWKrgSIX2p+weRsqjt0qXtri8ZCCqdEa oSEY2oQk9h8w8t8t6uHw+WIKQqDTrFgp6h02OeIYiZzGRRMzPtLnSZ8tQmMneqIJ4ls6WmMFDt4E ngiSGf9j31UUBCHSEsJOyI0Rz3FcE/rHOaLjHgJiFw6i/LnjO9JeOVqbLo4PtgGcItaQPepaKXZc LQlkgmxf/K3jFz4aQv6iQrJjNS5JQ33a4dRjN9qGNmocRn7iZW1iRyrgR+Yf/hEh1hFe02Bb30Gk tx0QTbhhSw5knr3ZK67KQo7kTM6fRsYZUyklQyplSZYkbQCl37mGzQ0lT2qNVipdTLJeUiZk+PFi L4plWErjiVAlV7ZIxumdAG1l+eBQO/LhQY6hWTajOo6lU97kXS6TIVoNkwWWSX7bT76l9hAmXDqk YSZmFl7eLpqXJtbkRuIlTUrmS6Ijd/DarlGcWxJmX7b/kmJupSGGnErSzgIG4RI9ZvdFZmPm5WrG 4x3aZEF2ib4h5mAmZmfm22dOUgKRpm2m5UWhJjxOpl6S5XAen18m3yh+5mEuJ2cyZ1wNYxbhJmKK pkfqE3CGZFfCCSdW51cypl1aJWbKZSG6mHLS5viQJlbCWbZxZtSZZwQ5JwVa5zZB1VFq5zVyp+Hl opMM0HnQ2SM6Uxk21GFSZ94VZm5Kp1bajoLWXaIgXxjiJ0G2ZncimUzuRTUxBVUq4SMWzjDGXHmG 5oDCJ+FsJcWFHVaGI2xW5XZWKHHG5YSK5B/2ZEz95G0qxaVB0BI63a+xJXn2JYhOp3P+RBqVaHpe ZWlG/+NeFqdwxuiLwmgeBsh4LsU9TSSNgpsyruK28Wht/qhELeiCGmkZgql4yiMPPiVYumiLommT UmN81mdtACV/2lRE+gXj8eOGeqO2Uan2pKeX0pzYIYV6wuT9UaZrSuiajulzPuFigmRW3RpEtuE3 1qicYSk3otEEkSJPXpyJAuGIGuUKQihLFeVdHGqKfiei2qcnJpLMSV2WZumL/WeWotct4aOR5iMu 9uGnsqh35qGhkuqumqmi6ieFUkuUTio/tqpWFUbNfWlg5qitBoWkCqsPBmKZmmqwLqqvXmubiupx cutZitE+VioyZqZPxNwM2UStISnAuKSQCeWvvma2Iv+qm5JhdqJaMDkqrUaTK0YoM9LrdojpsKpp tbpru2JrqQKrrC3l3E3jrY4qlPqfxYUpuWEcmKIGWmKjE0WrTrIqA47pvHYsv5blaYqggzaswxok UsJUDNrKxUppnj6pVWUbGJlnTawRes4oyf7gxxpsrvJswA5Zvc7lfaKqkx6jkr7GVWJoXfybYFIn gX6sHwrsQv2gup6qzgpe1OZG6L1beW4mx2rNiVKacnYmn5btwopsoR5t/ihs1Wor0U5rUEImCw1G nOJQQ3mpTHntT4Yt35ZdiNLminrloAbnwKoTygbZ4DblwWJsZf7RkFIclzZn90Dry9btaJqoRTIl ta7/rdyeIa4GLeIGjuKeCcjeT1NWGlx2pg/tJuYukF48Lt4u4s2i59mCqhNRbdvipNRyLqH+bMNt 7uI6WXuW7uUZIhzx7TK2JZBO7l8OZeYKhdOKaGo+LNvm7ruGbswy6fUym2p2KkKl65/c0ooVIuOd 5/G27qYyIdQZJoEuL2gibOMS7uoZ7uFKXuJqb8F+7twakAEB7LAm4ZXinD3p0kTerW5CZ9n6ZNd6 pg6FKAKj6IMSbOFKq7fSZ+C+bQXHrcWG5rNCbiE51LZpGySNHQSj7/Bu5nvqra2Za9jBa9qire/S L5ti8LoCr+dqsL9qKnq94OKp7CkikNF2qa+ZmzAi/zB5ImgD96b/uu703rAL56+ngi72Zu/uOjFG Fi0UBfHefVWc1lQ3Qu6jOmEjllGxJuHYpm/FxYb/XqdvmuwU17AN1y4OJ6rudq6igDEq8nClEjGn ReUOu6A3BjJFmeu/sXH3/QW7TjANM2gcz7G11vEjZ6+GRoQauuJDHaEWUypNTayfRtxt7qxpTvCT RVHLMm78qm0Mx+3O1l9cUazAbZqnCTIZOxlXzVCzXiyRbm8oz++2si7uqK7y1ijX4q8it+QqC+FY 9pse66kLahu6mqSNLrEVk6kU0zFjWq4ecxvs9i2A7HIqB+Ux65Sn0uiA3iY2zRwp9lEpJzIvw6wK af/sYI5y2Jnk7OJt8C6y28IvyWEx/Marmm1orWJzPRIvFC8zMbdzP4NXjUYu4FIa8tpzArux/dYv KI9uQRO097Ub5NqS1GCg1r6sHRvygSpvK/ky7b7RbtIzROdcCquw4EKyBCN0Dku0L1rwN/eSSK/z G8srP8tOvpm0SYcnDR1wgEIvfEYvzc50BrPzTT/xgYn0mnnzNNsaPsO0zy4QSKfsSusRx9EObSJi nya1VubazPamWWt1Pit1adY07grkVDP1NFd0EkdyIkHZbAbzV6Owgc41XiOoWEuuYlY0XMtxTDtm W8dxMXNvNX+eTtds+kKK6rb0XHNw1E22XiOxS7f/9HIm8SI+71s3SvFdLVgddu9az06nNUb/7KtK KnhY9liLaArH9lFLp2u3b1736NQRdRtZ9D0n9FPn7GCHM4II9wzPWXwKFlljGm1vNvsaqORqNkMD tg7F7twh4rNiJm+/sClXqydBNVqn6e3FdU9P9J/GcmWT9S61Kq4x0PL6qPtGt0oTtT8a4RnCc2Fz avUqbNbeN2F/N2tOo1T3t39Lkl1raEoK8s4l53unt3NHEPqGrUqjtO2Exw1dsDvzdM/2stXqdzUH eGLHxuJltcJWbrKmZDceOLJG6hG/r1uq4YPPNxx5+HgTN9w2sYBX9ZL2IE3L9JseqzXXdaMm94lb /2oz26lyiyuyomGfbqpnB2gayfhiR3mGXzhqk3ddAi1Fj3fKpjOJhyuO8udEYWmRy/IkkxEx2myY pvmEB7eWQ+0J8jeU1292N3Vq07mGh+yB75zOGfkmu6oumR2fI/i++hsqXqiUirab0jgc23icF3e3 7riUa6605LksI7kXqziOchUJT5PMkVuj17j8Um9IY3lvq3WVKzoXbuexdjEHB3KCi9GZB1xFXpxU S3M3I/qVw7n1XvSje2ubIzNfivCd7uQQF7s/xvKcB9Z+X/Wtj7qgOnqvr/WMl5Yy6XmwDXHAsVGy O41NDy2z7/qHU3OWR/oORrHYUWwTwtS2D/N28/9uqH92ad+4uUP7j4e7P4fK6bripy/6uze7s8em RAe4d995d1p5Q1Yxt+N6rn87uNu5wJN2v7O1ivi2pNvxmzP7shO8Lm97w9s5qr/ow5v6Jyl8ksKw w3P8s0P6uPtqyHfQumc8lZtufnOknA/2wMd8wds8aVM7yZ8pXYd7ywO8tJM7qaL8zJesyoN6aKf8 Ujfy0Ue8xNvwzaNqRva8zzM80x+p0Xdut5f71ve718270pu8vIu8VVPw0B+uP5f9aZ89zvO6h1M8 3kx9tG+40z89dnq9zuN9G3vexWs83H893SU94a9p0IN91jNyvWv3z/P44TOsr6/9wdvu9go2Yk// /uA3fbx3vHjHK9lvPN+3+8mzubdjjSMjPs3T+9p3feC/vb1r+b5f/UsHvEbD/t5bfNTb+K8Tveb3 qqj7PtvXeY6LPryXNusj3br3PPEHf+zLPo63Pofvr9Dr4L0Lft4vPNorvu8/vPRnftoXvfV/voWL PRVTPvQzuv1a5u6zfPgv/9jHO8wLbZXzL605/vHz/vcf6uOLf385//MDhD2BAwkWNHgQYcF/Cxk2 dPgQYsSECSNWZAjAosOJBQHYy7gQ48eKGw8uHCgS5UiSClOaXPkSZkyZM1e2tMlw5k2aMnXyvNly Z9CaP4H6JIoyJ0qMAEKCvPiPKVOXMXsKNZrS/2pWrVspHkV69SvXkjaTes0odqtZkWXVqqT6M6rF pfY6CqxLd+DdqkbR9vX7N2jbs2DXAha496Vgi4ZpKnYLU23Tpg3ZtpQs1SlmvJsRMvUI1Wlo0FMZ lzZ9urJj0onJMkY8tChs1KxVayRc2+BdhEcxg+wd1W5w4Z7xjs4Ycnhe5bOZNxdb2/bb2IBfk6zu XCh0yreVPuyNU7h1h5OPk78oNfnmuuvHPzWO0a7ug7rXL+dcWvtj7Abzg5celrrW/gNwP6v6+yc1 3OiSrz6C3EspKskygy89gup7TzTRlmvwLgYn6tA+EHfq6cDtDCsxwcECnI42rArUCsUBoSNJvv8H jbsRqghB+w64CtdjD8P2cOqIuPgspC+88DxMqMG8euTsOvFKRJA7x1Jc7EQBIdPyxcAOvNIy/WCr yLwMJ5ssRCI3NDM0yZScr0P57HuTMw7jQ5Kj7wrDb7W/vqxSzL64HJNAQj/yyLU/YezuMRHHCvPG pXScCs8kHwwJ04uSXFK9OTmi01NHn9QNIj1N7PKwKY8CU6JEWZTSRRkVlFU1Pl/dqCEJIypT0vE6 zY2lSHM10VE6K13yRyadjJPZz26VEzVVvQK01SxvxfXaiWKkFctHD0Vr2G+5lUvHXnO9z8g6Pbrs zOgqRRdUYy3cMDc186wrSuyk3TdbrvLdbVD/bPtDNdhYtzQ1XCrHhXBHNNN8E8cgMf2U4orvg7bY On8cNTzvVCTYWX4/BnnEgAU2uMUZSQ65UFiRglbdVC37LcfxKKS4yYR1nRjY5DzkdN6gYc54wY7+ dU7kgVc+mj+TtVWaZKYL/grmksoMUsgcy9ywSSCF1DXomO3tWT07N4Uzz6b7fanqkpN+e+q3o9ty bW+1W9rpjYo8CaKkri41rlzjklTEJvNyb2dNeyZa1HTlLLzCeKXW6smu5BbZyymp7XtztfCuu7mb IjQvcKjgDdEuxMmk1+eh4yXb7IrjnDzay5OezXbOF27rc5RXqnz0vVkVqXQJk0T9sL/Bfhh2/2Pb 7no+UBEeGdXcMV/ZwW1TVjnqvDtL1kmh47TcJsxGF5xT6DO8NGH/Go9ednmP95Fv37u0nl/s+WIZ f++R9l8mwiOOAJ0EOKXoSUeO88wA1aQz0egqa+1SWNjeN78IIa9o/BMXwfpXm0n5R3+GAmBWRoi7 EqJNKHur2QrPs74WVmtBMTRSkRioQJk9EIcuxNrppMc1aNHuhrrLXAcFwyu9hTB72kOiX4BomvLY zDdQzBGcRofCGsYwiiv8TenahMP5xeyLrwPY3La3QRESMTJkDNsa4cdGQaFxX66yX4H+RqbpfUeG AiTSHi8ovCSaD1OBfCEgbRa/Ct4rO9RrIv8cRWcwjLGtjZ1x4xkZ2a3etexF5SOk1hAow7QtK13h 84zgdCjFTaInj+Dz1J2O1Dby3c1AleQdD49Itlau8YIfOlIpZUmU0IGOOUThotZ8s7eNeVKVrRyc IEnJo8tUa4FXpCH4GOhHl3FvRb0M1O9gEk0C0hCDHTqOA7UpxCXOxJok1CQpOdmUGE4TmfTh0I+y KMVBkkcqqDSmK4s2zVzuznNy7OXWTLPHW9Lvk0aDYKZsVCpyWu80fWIOPEP5NE0qTzNXTKUNPbnL e7aJmfZEEEU3Wrk7mfSTdsOmn8rZPl1mBUTW7NEAnYc19mGNobxkk07N8jlUTbOeEArc+Xz/01FR MkueCiwer87EzHzyEYXhW9Y+EzS9n9hqjiptJC8fuUpJSpKq80rW41InMdVlzaE43enVJBixbRZI QNbbornOY56jnrRwXR1lULUYSHwy9UgcrWK9EmkWq2IVkxYtET9P964vNstxygHRaHLa0MR1Ea2W vakESTepm4Gsib/cFeEMelfClnRjd/zgB/ta1I3GM7Cvja1iYXnS55wwiI6poyX52at+1sexPsqh hHJaR5phlrIeUy5leVTXdMIVt7FUIrCCF1vhZXGTdSWXO8smVX/K05hlseqqBLonuqlmtzdF501Z SNOziUi5l00ucnk6X/tWVoduuqR5sacq/70Fr6nD/CgLXSvTsY7vt0OcWWLTEl001lI9IkVfOH8F xl+xdbhnZW5mPlJc7Tqlv9G9ZES3Szj0tUqaDPpnvZ5b0dx6sMWFzeorIcoTU51vLpCzmPzwstBw 7dbDZtVie0f7WQ6KeL8fw18Cw5rO6saYknwFImPjRr1r5m69L/wafkOTRzHia7NnheB7lJfhBy5F cd0D5hJDexiCkRSU0i0ieRDL3ysTLz85yeeJJ6ThcHkVvplSrY+FbF8yk0m73KzdmpHY5vOCDMpj zPOHqExjM0b5djYmLlNrFuR8ijHCbiX0eHM4X/Ox90x9qbRWrXxOtc24wSjz73lrm00GS//6csi5 zXGFNWRfXZh1T7ljqVFNbESfeTQxWTUkkwhrV9MFzxIFF24p01JLspTRL75cN1Ml6L/uCrlzoWBu MCtfKf+4oWotJuAqvWy3ecdUzz6ZzfBJS6+WsdW0BcqDy3vpO2/7LQj066l9ndz4BYc9xyVduf1s Uw3zqst/cbfRsq2/Dquxh2G0DzHbGpfhKUaDK512xfkd8C03F90Rh5662tPcQFrsa+F2oYAj3iW9 MEzels53UCbrVk4qbmzArmTIZ4Vpcxr9espmJ7tLbTyiLUfmGEqpZMt635iTeXlqLvKpcp699IJQ 4uMEsQU3zvD6QrTktK6xstl6aoWnFbL/EKPrwqm08p6zN1K8tmuSd/5sdg9T4ySkK7qDHufgaPbh 9CU1lmeNb94EdECEbl+5xc24+q3P6UATTtRDyucHhbjioG9ZbyHjTCm+E36jNK6N6G71c3MZ7dYW jHgJPF7JGy49YG6YQ8N7rKoHudDP/Bt0Q893uVilbX2mN9CpnhxDJ/7YvZ48TiHucyw78eJXJQya AyxIc1O3x5Kt/o4oVbUBNv1Szmxrd4iP8a5rEMBjh7C9yd3yeHuZdc7ysLnjm+6Hjp+50MxMFs92 iE5Vsq70MGzdoEjvcm9OPIb7nkJZnM/YcASfiunrju6l3k+02qLeFK3qiAneHidj1gr6/xJnzPpv 5ljPqogqrWRP2lCjcOxp7vKrTRYn9zCPwCYI4cIvPlaQvkRwBMWO67jC3d4N7NQpBqvM//LlZ/6K tHQtcoZjuUQt5VxvZ9ZPBUWNALeqpZpNZMqF/CjPOACtY66OoULlh+KrXQZtDL3nCAMoDg0QhhgL LjKQCIvw3yyw7vKPVJrw+SBwqK6QoQiO4AKx4fYFD0VuD8NQAu2OCoctinDwVwwtBZfrApFsAhfN 2V4tA1Xr6vzt3gZxi5KQjQwR7ySsAqdP3QLw0NilpRZRFPWtE0vj7nYP856HI1SwEC0L5YrPCOXs 1liNeFgrE+nOYQLve4ALT8bqAaPPzP9sCn4eahV/7sQykRVhUAPnTRvLRwIr7HgukQ/RUMuKkQNf zc4aUTEEcOlII33Ohooo0b30z+ysTwcR6j5eUHU6S7eqcOg6J38gTTmCEAoVkOZmMZJAi9oU8VsK Dx7DUawmqUEmT77wy1w28PBcz+cOsgvTKLOk5eMC8j84MYLSTxav7RwXySM/kr+ozCEv5hSFJt3E Ue9AIv8qaiNLct1gb8kCDOQA0iuIYSGIQSgREtfSsc5ScRhdTSX5BQCtbLBQipUsRgs5iyLdI/XW hCATkfW6MRtRUh3VoiiJkizJcijHkhgEgiiRzv0cT27OkQnBkhvhCOKiKoOax1KEDa3/qvLHYnLz tnDg3vDDvJK8AEowiJIhEPMfynItC6IxB6IxFVMx+25RRJIDm9Ib5QqD+ikrLax54K59HAtPEJHL igcQCXMp47I/JnMxzRIy09IeHvMx+Yc1W/Ms1RI2R64W4TIs21LnvOIke2q27hKMDonHHgmthAaX gM8iMaojp+XyAE7taqM2G0IyhfIgZjMy0dI2E7Mo+2Q2YxM2t5Mt9fBkeDM6kZIWp0QcLUP8pi4i xQZ5gkvHGusmhwUby7Gp4ggoC3M6qfM7z/IsyXIjyBMiWHMy17IsHTM3Y5NBH1Q8BdQoibGD/lMu 17PDvi44X5DONAZj7GUecQ9d6rM+/+GFRPlH8myrlfjTMKGzRYMyQL2TMXETQh8zI66TB8VTNnNz OxtUR83SIWrzOmm0N1HzQn9TmBCovk5Sjxaoo2JnPv3QlhyQx4rjxzzMlirnK13UQn/yRcWSMbvT JcITQhMzSLlzCcVTRw1CQXmUR2X0TIswPLdTQo1U+8pzJYvtNE0HlHxPryDxqyqMGRNSXUZtWAgL sgxrQtGREedSNRgTTcWUTd00N+v0QIvyNQmCPIl0UiE1ThN0LDWVQDUVDMVUQmN07Uyog1bPJkeR Y3xwCg9OVLpKUF2MnMDmVRMMGrnULWevP4kCVAe0LG+zRhv0IUBVMTk1O310TnETSP8jAlK1c0ad FUGFslorojqt01K99NFIUh/zbLDw8rGktFZdh+zcCF88DSsPairpkGG2EUO5tVfbAlWP9Tt3VFlf 015NNUd3VFonojFl1FMX0xRfc2DrFEefFUcRNkCFdCwx09Eag0PvMKEOjsXmhKzI1XBeUlTA7WvC qUgUZcfmNTVLFUDrtVpHFSF2lGEvdVl9dFkzdS23NU4VZk7HEzax1VoH9lq7E0iDVVghFptyZ9Pg M+NWThk3NkulR06s8IG45numi+2Sz8H2JVuJlUyllWa9E06BdoKi1VkZFWgJlExFVWYcdmutE00X 9lTrtWTTs+ha5EX6KEortjgJaAP/Le9wqM87AlWcRJaJqnY1r/NZyahscXNrG/Ze3dY2F9RfFzRC 7RVVJzVTqZVx+RVtfbY6F/ZyYYhkhfNLc3RuWUdvOwVvJylogjBS+hRjNxQYuxRekfQwCXdYW/Nm 8zWIrlZzJRctzTZmd7Znz/RlfXRfLbV2oTVGM9d2hTZu8TRNHbXWLFZNZApqP0X3xk8KnYy1/NGX +o0yVXNw1fZw/5VlvPZSr7ZNKVc21RZ525R8GfRS+fVYubZmkbd7Q5d5v1fOfmo+XYfzvpGHnqQf HyIp9ddk84N2A3RlGzRg41dbi1d+ZRZmLTd5d5Z+W3OBEfN45ZeD2fZMzVJ31VN2/2cpdAvYklgU dqDvGyGLQaRWGWE3do+SOiHYO4uVU+33gh2Ya0cVX4NFg93Waw82eMU3UtOWZxf3fj+XV51XdHXz bW9IVTExTcjKhWkCZvLXMQ72glUWdzPXg3mXfrOWWb2YcbWYfVu2bXO4fjc3TO8UhkH3jX0z1nYT bg34NP4WamxNhGUYOtqYjQuUUhVXh3dXUh/0cTVIeYnYIsw3jJG4kTeYhulY2+SViU34rUaYgBWs Gy3Zc5n4JhS3cCljU8X4Rhd3iGu4cjf1d91U2xJ5h4FYkHk3ltN2jynUV+PYPG+L5DRRYivUe4+U jwH0fCGXU8uWYCOZgwX2NnsYQv8lmIs/WGEv15XTmIazNYQ7uUj9U4mfVwkl2V0zOYRQWJe9uUTY +ILVFGBzdlutGVXZeFppdJRxdllr9prHVpor2HYj9ZpJeJIpOZu5Wcae+Jvl2O8y7Z+bOF4PBGgd tJnROZlz2JyFl3Ib2pBx9pUHmZBxmJo1Wo03+VcReo4FOmKPzE4B+oDDF05jsIcj+qJLeUxhVowX GH6H2YMheUC3+J7PeJ+/8KM5GZxxuWC7roqrp5xhGUgn2nKJzp4ll30P13e7GKZhuX7X2ILFV2cL d6cLcExCMpf9ZSFfl6QnDX8rKVovF50nemanmnB1Np8x2GyldYInmmZZeqqHcpD/fxiZGcmnfxrb yBmsiTqPt9naUpY1KxdX0LeIg5Zh49p90zKqz1pHReKU2VmnUbZ2r7Vzk06PF1UYa5lRObvRANeT ebmz69SwmbmjhxlaBfStWdmwGbSxoXlzJRufaVmI25iIwCSYLzmkPRt8sTnnhnq3b7mXGw+2zzax p/lAIbu1K/q1EfuHlfeUOVpYM7t/PnqkKxm7SfuNAnu0/zq0z7ep2xlTcVd9GfuIj3e6gzaUh3in s1qzBTu7D5qrtRmwo/e7vXmv+WVY4fmxnzohcJuqG9l4F9mRIbph006+BVdMsNifM8m7D3q+ndi3 Z8N91TSmnaWeD/yMj9lU9dml/2n5Lbc724Tblvk5rPEbeh+8/QT6pFWcSEHYWiN5w1ObbXtWwPGn vpN4wXc5wiH8xxMa8hQSvIEapdl7llMbwWkajna8Vk4cjnu8yMcZxoU8yu/bxb31bRwWxPNaybV6 rI00zPX7l1kck68cyMkcPb0ao8U0x3ObxEs6VVO8Ua0czVu8wtf8xbfcug3ayOXcl7Wuys98idM8 y9ET0DUnzhNdOum8ebuZx7EctPW8jq2k0q3NyRl9zu9HtLtbzTfbjindxIk81DVdG8N50Ht70kls yuVt1Cmd0E190y+z1Yc7hv+n1pmy0w1d1nt9wvF81Z1c9A4dLl89igHE12Vdz/9/3db5WtKDfdmD fD+YvcyTHZgLOtc/+9o7kNiLXdr1hbsl3NrN3NXDfcWBe9oZnKBJPdW5Pc+R0LzG/c6F2tztvKtx 3a+zvbSfnN3fvbhFOqhBXZxTst5j3aRZPd8/va/bPZgKvtnX/bd/uqTXnNqhHOKPPdgrHtLrPN0V XrtLOLihXdD9XdiNj7e1fdsb/tvHwlo8/txvHeVPHtbLXd/3HOZVPuFJvtpR/OP/fOednb57Z+Z9 /ucvXstDfaDv3d0f/eWBvumNHt6RXuP3vdsdPeUDWudbHuBrPur5nehBXuv93eEr09R7PnC5vuuv /tLRHdxXPuZhbept3untPeD/8V3e513VkX6/lf7tbx7jvV7KxVrgZT7ioX7v7z7bx37jM17xqZ7c +z6+zz7ns37hER+kO97lqVzsGx/rmZ7uFT3sGR/t/93yOR+TTZ7tH57vcZ7hCx8ki17m416TSx/Q n13t+zn17Z7jVd+4K//6Rp72G13UvzrzNd/zDR70fR/M+z34RzztBR/5d3zYd9/iB57Cf5/5m9/P hx73D777577toT+/W7/zhd/2td8yrb73ed/7Dz/Sxd3tHX/7zx/9Xx/4URP1eR7+xd/TZ53XAeKf wIEECxo8iDChwoUMGzp8CPGfvYkUK1q8iDGjRo0ROxbcCDKkyJEkS3qEWHLi/8mVDVO6tMcyZsKX NEfKvIkzp06HNXtu3LnTp9ChMIESdGk0JtGfSVcuJbpSkKCCUptavcrw6VCsXAdqhXo1ZVeUXy2O fVj2K0OpUxVWHfj2X9yzdFumrVk3r16uSPcevEvRL0LAhCmybSsXMdy2hxVTdfx2rmCdhftOvjy4 MseFljEXxnxU812DkSEvFsj2MWrGjhcLUpk4NmiFoknOvi2wZ96QuAn3rl02rmTZB0tTJVj1MPLX 9qQaZl5R+fLhXYGLxH27NnasvrNbv+u86OOppSG3Pk08cfTXh9evXg5fcmqc30FuB13f5n203fHn J9reRI055xx8xSmW3Hzv5f9mEYHhNffaeOQhZhx67w1HHYP/XbTfZRtu5ZV1WfXn2YfBBSggc+E9 6BqF58WVIoQPQhjYdI0tGN+EC84l3IDr/dehhybiFdGQS3lnZE0oyrjkjzGmuGNrS85IY40JEpfh gBXmCJd6VT755YxU+hTkZEm+1FFnZ8I225opabkeWz8+OCZp5q325Jg34sjnhaz12aJ0VTkpZmo9 WgihgaqVKZibJhUpFqRsMkqfoyM1FmeAY4JZIJY6fuQkoX8mdmOFGN55KIzPMblihDjK1yOP5y2k IKU3WaofWY/qiqatmeFako8XtbrqsC+ax6mKHCqK3p7pvfqpolUWymKzow7/yCxqkTaUoa8SAcsb r7nyB1iH4ILUqpzPNSmgRltSpyd0z0G7mnTZynaqnd8yaWxgW9Z7YJRwbeutU+cyJe51Catl68GZ ytugpipCl66+ByaLEbbP4jvqxveW1m/E4pEacHpSItZZwWkStumRktr2clncOVwbtS0Xa+CheIqc cbSkCnqyxc4+y3OxiS768azq7qqyUl9BnC6dENsXs8ILPzUzzU9PSfHURc+bkKp5dg32vYFamLSd MRZqFmlow1vqVCk33ZRPmIZcLLFH80Qw3+Va9VmjLt1ttNRPunXyRjOeJmuXFpf872J4xygwoAfK NzfdRtGkd4pLg5kRrJXf/4zRyn/XTaLfI5/lrteGG7bolRoaS6VcYSvtbGQIZRgme64f+7aLgXpN teaAvxQv16C3ivbuUE889tVYh3U6uTD7pfjjO4a8pPMbZ4m7tZ93bta7QV8u9vWoM10iSYTTDn3P FVUepdGKI3gta9Unlbpd7PufH8SFalX5ItlafGY5omGMRgqKnI3MM5/MBaVvQuqJsN4nv+YkcC5r Y9vefgY+US2NdMs63v5G9D8Uai10plFNAWvlPHvl5mZQo195zvYXCgKlf5sbHNcwOMCylUxDxFuc loQ3KBZmkIBT69ateMiZFEZRM7gRHZdiV6slGnFWWMIhjiRIGSiGMVjC8v/c6143vyEu535p9BgH j7gudoFOiBxz2glVOC4ArqmKd8pR0RxUI2ZZMYYkLOH6THQSH47vgkUkG2qsZRAlGut23lPbw0bY tUo+TmeSG03VwiW9FfLxawzkZB3VyEEdjtFIpkOeHMdmPzr2SW/km5TZuiWZWBrGPRrroslmZUZ5 FbJ41sujHleopjMV8Fky9NS+1NfDJLXyUkFklYXARy9LVtN8IMTlsVrXNo8585QgCybxehXKjEwT mapUnXZuZ6+hPdOYO5TmJ9FlTmHmLnzBu1jvegY0oXUsl0t0jyYfKU4YxS9qrgoNwoppNYiyE5rR DGDYwJiTM63TfYvc50H/HfieOTanZ7/c0zI7+b7aqbF5gowjQxt6SHpOcaIYfSLT3JS1IW1UJBjE VLO050bFTKuRRTlpvRr4TVIeTXYJRNoaW9fMisqUNjRFJ//aOZNA0m2P90TXxD5npYG6SKwG0mXt QDrOpOXtd0DVmSnnyaoampCieKzqVDMqRarSBDtcTadXPVjU/FUycp3z4PAAhdYkxotDpgLeJtuy wLhSL69ZtStlK3XZSFrWUjtVnCTL5tY+vhWW8cpmP50qkVquapb8FJ42I7a0nEbUnZsl5lUzq9na arSrf02pPK/p2p8yqLAQE9gLO3Yasz6PpXx6q1d8GyDZzrauulXnZOk6/9PqIpK3LHxpcdPG3Dp+ aa2w4aad5nOqYMovW/IxW2y6BtY2xnS61NWufG+LXb3a17btI+M547jSlb6RqOH5HnJtd8rQUElP jHMsS4UDW3X9dkR+NSR3aytdUEp0v0LZC0/1OTUQHjDA8wSsSrzp3AqtdVOsRZoDkyhSM3bWZXOV qUVrTN/scvg7Ht5MSa3oRC8pdXWNQ+10ntvE+EGSi8uEMRopd+EOX/euv0pLhvlb3x3vNkhFVijZ WkditzVvvHhjZnDHSdBN3W3GYMGxhmmrlSs/FM5a3rL1+Oq5wjHnl5QE6uwiC6U+K0p0i7Qfm0Hk ZiwfGqs2zW9l68zZCv+HE67blV2X8Xe7gmq1uQiilVDVO8kok2nKOV4llWVS0xxCOtKS3vQxeexp X4bUxBELM2rT99nVZZnG832zVEud1Va7WsertqewbblrX3uojIbj80GZOzkZi5pIiZ7zWKydbERv uNgfWvSk6czrHqsztFcU51GH7G3dVNvHTaPitrkNpGkPm9jTM95pDxVHMMt7r+u27lbhDXBGq9rR VbbyXLED2DXv26r4BbZefB3wiJ86twQfuMF7XXGMIzvbUu536dok8ZCH+9WK1u/FNd7m7QTO4xY2 k8hfXm+TO9ziMiN1nA1WVTmzu4IwPxjJ2ZluaqM85b+2c8NnXpeeOyz/6DhdeKpRLUbMqu/GjZ44 XZTuc6cb+91EL/rNWX5f4z396lhveYhgfey+cl3bR2cY2MM+9Pr8puxwp3fMwb30tiPdjp58+7zt XTC6f/vnI+c4sHT+cb/zW/G69pVOpS54pjOc8FlnvM2/HnezO16UBY+81jMOKpoiPvF6v7vXsb35 vlNa8FHvPObxXvnMD76eqi/9zgPfepmzXuAUPznlzzV6zZva7bKve8Nyb++8p33sDgX65VE/fOKf /vbeWnl/Ay555p/d+Zbf9+pNn+xtix35ZAd98K3efN///vDPp77dC5/+jb/f37D/O8/V73Lczl34 j8b//MF1fsbXfzXX/33Htn/+hz28xxKPR3PSt37sV3z253ol92fyF30UOIHQ93DkxzoKuIA3ZVfZ Z3S0Z37bh37X5oEmuHc4B0rWd30ryIInGHpbV38A2H6kV4OzJzj6F3/KNkGshCQlmEgpOIQbMoCc V4A5KIAbyIMq6IMXSHUv+IR41YRFuHvqloRKaIHiJoTf535QiCsdWIUeoX1WyIHTd4ZmCIMVOIW7 QYReSH+2F3toiIN0yH+Qt1072HERuIUZ+IVM2IVlSIY5l4V2qINgKHefVxkBKIENiIFuGIhvKII0 aIiNCHVjOIm194BtZIRVt4ZwWIf5J4ST94MTxYh9eIldmIkIeISP2P+KouGHcbiJllh+kaiJhheG NxiKiLiLvCgiC4eCI4iLtCiGtsiKsQh8uniHnuiKfMeAa7eMSYeKkKiKyniIrwh/2DiHlUiMH1iN 0AgckneAhAhyY+iCs9h0hQh42oh24LiE1HiM64iM0TiD8dh7SMiHjSePjhiF6KiPCXhH/+duqSiD oLiHWpiO+biP/piGBnmNgGiP9fiJxViQ5ziMCQmP07iPfXGLAvmQGemAF/mP7Bhvy/eGIbiQx2eO J4mJ1oiF7tiNbNiMEEmAMOkoKamSxliRksh4guiTPOmQEGiTGFl99OgfK4mU3yiHbOeP4jhZeviO 94iPKgOUCgmMV3n/lB2pezPphFyphkqZj2pHlVXJjRrZg14ZlDHJFwG5lRo4jx9JkFe4iJojiC6p lj/Zkj2ZlDuZl0NpkSA5l//Wl2U5km8ZlRLZhoAJfm35h4aplqtYk4oIhIIJlmXplKVYmIqZjSR5 mM0HABMpmZEZTVD5mEFYkKeYmYiJluPHlpzZmTL5UACAELL5D7QZmiGJmcpnLmRJmEyHk4zZdSLp mythmwVhmwDwmcj5mROhnO24lB3XbdKYEchplMGok6DZbg25mQOBnJq1nEVRnDpBnfawnM1JntQ5 nuXJnOTJlCQYkThJEtTZFd3ZlFgphanpl1X5ngYRngJBm/3pN+ap/57sSaDr+Z0DSqAD+p3V+ZWv p5fgx5zjeRES+hD0GRHKSRAY6p/KWZ4L6pb82JjSeZ246YsWAaDcmRMA+p9n16ELmpzoSRHJuZ7s 6aEyWqAHuqHFeaKQmZgi2lccihMWWpsaOqQ5yqEHaqNHeplZ+Yl/WaLveKIqimpHWhHN+aIKOqHq iaUwGqEoSqS1iaJg6p9jCqLBSZot2ImzuaIJAaTcKaTdGaHnGaMt2p30aacrKqGV6Z5r6KRUeD07 eqH8yab8KaHmOacuihEdOqMHaqIxOqTHWaThiadhepyHGqNmCpAjmohq6qad6p9yGqeF+plFSqqk WqcvGqGGOp4bev+fHyqVi/mkatmmMtGf/zmnNOqhCVqgN3qpEzqj5EmmwWqcYiqmsmmsGdqrqtqr g9mbn4dnoBqniyqpKiqboCqqoWqs/ymkpSqssWqWXQmreNijgroQswqoGaqhkNqmunqjWhqs1Vql jtqtZAqpxCqstpmqyXqrvLmn43qW4VqLgfSmx0mb0Jqnt2qqBMuqp8qqCdugrqqaABuX/soS55qh XkqwknqpjMqoxRqmHvultfqxUkqsCnqwuXqadvmtsLmdwBmYDpWn1yoe2noQd9qwDsuwRuqpeKmV foqdF5uid7qjBGugywqsY6qulHqv7wq0Ivupvxqvu8qv3oqf/9r/shM7mQPrqZ5Kszd7pF1bpzy7 nw+7GRYbqLOpEGv6qEhbrxZbr2CqtkybtPTarcc6pueJoFV6sClrlSbJrCI5mTWrsFwbslortqLZ ryAhqQ3htCeho6eqrWtapyVrqkxbrnK7rZQ7t2DKrgJqtHpKtTy6mre5jcY5qw17uCTqs5+4uAxh tuhKqNlKtx7LtiA7u7Q7r8M6rG/7qEiKnoY6td4quhDrjWLZqiH6qhKLtRuRueKpu5c7u7J7u/ZK u5JLt7qqqkoLtLP5ucArtRRbHUSor8rrjMgEriWZn3/rka85n7pLpECqtmBLudvLuTWar+tpu0iL oglaqEPxujFY/4epOxIoy6CDKHqS8qw9K66jW6GO66aRe7NeKsH6q6PvyquNir9tq7kSYbIISsBo +b8si6muuXi4y6n2CqAomXbnq5vPCZeuG7QQnKPVG71w+7E2rL+fCrwePL/u+y1W2q74ixKoKcBQ K3RnW6vZWrRGzGpDObyIm5vgG6SMm7Ho+raTOqnzW69S2784Gr8WjLcu2r/jqLpom5YagbKOu63p 6rlcHK2du6lO7KysmXEkS70xIb3va6deO6iWq65JOr4ESr12a7fcOb4de8M0WcYd8aYpca5RisJW /MO7iqgYXMk0uqjfe8T16beg68Ls6xB2DKiZa6FsfLvW28M1u/+sHnyeuPvF3FqsQkuchFmXvGW/ FyrDD4yvmAy1jKrJvgzMUcvL/Iu8EVvMVjvC6xuOidy+lKqka5vDSru5qFysv+rLVTqySzuwx/q4 WPGlLnuQRvHBski/OKzHj2vNwmyjgXzBBNyicLzKR5vKxkzOylzCn/yyuty4FUuvexypcqu95ayu h5ysllu3kry0CQzFVBvCCK2kHJrOw5zJvbyx8azOTFzRbBK3a+vOx8zC7RnFfNsUk5u79Cu90Gy9 i/vK+VubvnrRGqzFmNvQiky+EKGxzPvCsGu63FywGOzGp5yoEZ3O1xyz8prEGatDgNqnC1xvefi8 eby1DVvIPJ3/ynZ70Xgrr9s71TE9w4XMpD8rVV97sIx8saV8py6NquzJzIt7vxjNyvH8zHeMoWUY 1FdbvoucW/cxuFn81NUrp5d8pa7sx7H7wCoXvIxrxuNcz7zbz607pCaqpQWt1ZRr0fYb0ShbxVa8 yz7diyRMiiFd0x9dQk492dPr01c6pzgszQad2QoN1im6fR0tz3iMsbmRt+Pb12172hcs1Iha2Lmr 2HV4rg35xPUMzjmdvO/0EUQNtT281a5cyhF8vMbNhTg9KZBcsrIMzdO5r6PK2JT90uzMq4g8w8x8 uMF92GUK0scNyqZzfypxxQlNrt9cjp4MveSKzJ0t0Bj6vk+7/6VSa8aUfcmrDNjtTNjRXcR2DcB4 Tc/6zYwifRXxHctkzMAeYbZGe9tVW9gnfbqbS7cwLazcfdmcvat9Dc1nPF1L/eAKLtrITbYO+pvF C+GIzSvofcMbjdLOrNJ8XcHRrKPt7NPcm86x7LR7O5W0LL7prd6/GOPsXZpWgd7yZbYdzt8i6+Es /dwcnNGdC+IBXdqcS45hyZL27ZgDmb4LLcd70Z8uMdNtysb7POFbDeLwus51HhjTHL3c/NsofuTF 7eDJTd0r3o+Au7LW+dqJ+7kaXrsb7M+2i+dNu79LDOQ+Ps9uHt0tzW1+XsC1fOZjy+dKLuOFbpej mraEuugnXv+5f0zpXH3NE02jX27DOUvkm42Ag27Pn+3kok66LC7C6+3ZxH3XXNnapwuyPF6zG4y0 gZy9By3gohrYT9uaSz5qncyXZC7tsLjrHt3ruRjs2l6q58zRExzJlB632LvlyRnQf+y9b62d0X7t myycKqvigO7rZa7CLd7ekZvZk9u6qLzSYG7n3ovsWx3GvWzknt7u7k7vBazp046QuP7r806Rim66 v52tek7u4q7BWC3Uaq3aWd7OXKrJDJ7f4XzrCR7ogh7HDz/mgQt48avdq127xi65cK2vyB7J6Zms B4/wCd/z6pvr+cyQe0naD/p6ccvXAj3BkW2ghXrjNNzWEC3/zAr87vc89JpKvAuepp3Op8K4g9gh u/4eGpbNyzTvpRvr7NCq8A1u8irvlZzO9SSP7/B+8ms/8dZ+E6j61t8J0Dmspaqq8z7v6esznFcT 9BJf8g7P8nZv6PDG76ytIYCf4SP/kosP9NXd9QdM7U3q9ZgfnXpt8Fca5dad9duu+LhH9FrT8KBs vGe69ZZvWc8b8aAesJxvitme8gu/zF/9+Wm+Wauv6/Vd7eaL+3/O9rvP++j78Frf+7B/6K5f+p/O +CuL+HN/z89PtYKP/YTugNXv2lI87y5uwD9P9UHS+b9O4befnakP49CfzFUP8YzS+kGf/t5OanTZ 8oMv73QN/+zCX/QA8U/gQIIC7R1EmFDhwYINHT6EGBHiQooKJUasmFHjRo4XPUIEMDDkx4IcF5Ic aFJlRpQtXaZcybDkRpcxbcpE2fHlToM3fcasaZPnUIxCiV5EeFTpUo8j/yUEoDPnz5VMmd60+pCq yqBAszbcGpZlS6xfh5Y1C1Ps2p9HD0a1B0Du27dznTotyrZi2rNG+X4MS9YvX716u1b9e5hr4sJ7 ezb22VAu3MlQKdsTODKkZpGZL0NO/BJtaJKjAXv9C1msYpOkBSNOrTphV9ceLXbOnPvf5qdx6SKE 65tucJq1T6M2LtG07cFmZW9lLTV5Xthpnyd9XX16U+C/if8LF048ePDdeLer1X5+JvLj6bNeb5t9 sXqHy7/Cj16cvtuFUSv/7k43vO4iaECr7NsPQermIwy+5phjb7/H3Hvvuvw0knC623bjkEMCN5NL NxENbI/BDHuLEKkH78NvPcemSjHBFSu0EEYKM3RQu8lECrE8Alv6TjocZ1ywNcZanKo0ItVT8Cok lbzxRAhzNPHCjMyTMcYihYxNNSvXkhK9Klms0cYxw1SRStlcPJPJJbV6c7sm4SzzxDmVcvBLitDU c7UJ1TQyzDjBGjS5Owmtc0gtnUx0yjb5pPO5PgHFzLhDCbrU0kIxJXIsKTPlKU/5AoXUUS9HlYpS DPtaNFL/Uu3cVMxXSxXtxQYbTTNKWtkEDVX9djVz1lwflTPWP4UFFlhRg+UyWUTX9HXVLlUltj5j QwP12Gad1XRPa3FV7lo+ly0R2QPjG1fcaat9ll1ub6XWW2Z/fZfXXueV1rp4993w01a/1bVeePnF Dl9PBeYU3C3pJZNgh/MlLdtsEcbz4dmitZViFCXFOGPnLAY5MFYDbndbjfUNedKLTya3XJMZDblM kO1leFhzT6YxZukmPjLljuUdWOd7cV4ZSpJx5k/o9F4u1meDPW5Y6cawxQlNnpH+WeqCWXbaaHdH 1tqwnmFTGuuxwz5Y45hV3hpltMUOmumF4zV7p7drFnjt/6z7dftuP+PG+2OL69bW70qJ1tvrm5cy nC2qjyY88sL9xlpntg8HvHF1nwaaYqG71bxqtd+e+1/OQw8c5q9Lpapu1Nv2/HUq95b9pLMXT1ZN 1mtHuvYcL/f9cchpLdvf4rn2XeGJkh/e7s2NRx1SQHtn3mFZq4cu1OdhfV374BHH3vqSKVUc2tP5 jr17145HPvx9gZ/4yUkr511Q0SU/1/33aW+df3TxZ1z9oKe+9elvf/Br3sbMB8D6+O9z9jNg2hwY QcfdTm7jmxoDXUVB2EmIg2C63geVF8AIaSNcI8SfCNHnQRW2kHIWTJ2rtKEN+aUwcRiMjNVcuDsX djB/Cf8MywwzCL7BOTBdLaQNBL+XOQna7DpCjKGzbuiyKGpohxO8X5YsB8MmnnBmBJlh3rpGRYgp ColYJFsPs5iz1SnwYYeZoQnps8XyVdFQPURgAkOoOeG18R80/OJU4qiQOEIRc2FkI+5w2MXSQW2O eESjHs93QCa+SI4OuaQbN2LIU9mokAiBYiFFORBRIhKMmdzgBWlWRifasTZqzKMk68hH55luJpxM CC5jAkhbpmSQhAQkFEk5yj+asJQCQWQch/kYXXbOVKpMWC8jBslJ9m9dQ5PetX7STHtw04+GDCUu C9mQUibTnMgcJziDyctfLpNRsfTjCp9ZPXgqkig1HB3/5gpiymg+h5u4dMk6D/JLUBKznO7kJzrN OVB2rrOhCJWjMk/Zt07OkpFklFo9oek9jt2KhwvxZjd5CcrVJNSdviRoQcGpUGIWM4zmjGhMRwpS daITohO1qUslitNWvu9q1fxdJP2oUVfW8qcUpalGdAnQlqRUpcAc5zCj+lKJwlShDC0oVk2a05zy k6o8hSkqnxLSsPVRfEDN4TWxKTh8PlKpM8WJSb0q0pk2c6vF3OclTVnVmDJUoCIt6ElPGdW84tSr MR1mVumaS8W+kYt0E6o9wVZRpKrxRlstZ2ZpeEzBdrazIw1nQxnK1T92NZN3LS1eC5vYxWIVsK59 LV0//xlbyrK1iBatoFqHWEm0KasiofWrZtNpVdXu87d1PS1ib1pc1RKWtIRaKmgbWkrahjOXKSWr PH94W9z+rTSR3ahRQ0fUjpLzoJ497HXf+pCEHpa052SuVQcKW8bK1rWcxO8ghZhdVibyrN0VGVpb ZtvxCviBEZmqCRu7YPdCRKzPLS5fDfvX++7XujSd7Wvze1SMQtbA0tQkwcxKyw9vL3MEFSJ6k8tT TLJXrOp0qGIvDFtR1jepJu4pJTsMQqD2E2687S14a5slB69YxSzeKyrhSluV1ji4n5xxdZfc3+06 tsTx1CaIayU78nqYji5G8ouT+1T62nXKUJauhdNaWf9+ddmRjXRmjt9MQgICuKxbDiSYl7ngMlOX wUvmb3ZH3GYhU3l5WuawnElXaB1HzWcZ2TCfpZxhivxzyod88D3HOM/CAM/Tj130la0M5KLpUKnq lXSkOZLinaDWxyJm9JxTWdTJXZTOFV3gjoOsW0N/64iQFq1NXK0UJ8PaztlD66d5/WNO2xpg0QN1 nL0oWStma9iLrHSxOx1r2yXbiNHuNmAu52ZqDbrXz6Y2itKVGP5S5dLOxrZ3da3dQwORYYlWdLib fTdzw3uV/n61tL4M1HZb89gG37e04azvhDO8ZP2WNbobB3GF1xvLIPYhC/0Zv7YuvNQNp/esz11t e9f/mc0A3yPKax3xeG/IsvoEObIPvkaLpzvEI78jorkM7pBLnNY3VznQWf5vEs98zfP+eL6TPm2b U9zhTJ84z5fu8anXPLxCr7jIg15Acj+d6hm3Oq3x7d+fL/HkQw84ztMedI5reVcDVnrVtY72lGe9 aSU3OYHLnmWd912WSvq13y+O96Eum+4tP3B3ES/3xYN97nZvPM3DrnaOmh3pjvc55VcOedAVXtRr jTvCYy75x3t98mzHMdSHbMbBt77pUie9o8vNbdOXvudE5/zaD4/12lds07BSttED/3pSy/zy/zs+ zEOvfNVrnve31/Tv2+f6qzsd+q8MavKrqfvc1737ec9nfOSZX+X/alArwefe3/Ue9c/vXfBXH/vX Z6fDj3q++JgneYHb7/y2Ny/+p/ewASI+bBm+6oO9xEu+/qM+97O/BOw4N3E782u+rTvAgRs95LvA 8QPA7wM//Jus8mO9Ady/bfs2JdI/4Qs79MtAFSQ7QjNBEfyYgAAAOw== ------=_NextPart_000_0008_01C75EB7.523B1BA0-- From sigtran-bounces@ietf.org Mon Mar 05 07:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOBxg-000204-Ap; Mon, 05 Mar 2007 07:06:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOBxf-0001zx-BJ for sigtran@ietf.org; Mon, 05 Mar 2007 07:06:39 -0500 Received: from [211.179.3.4] (helo=mail.inticube.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOBxd-0005dN-Uw for sigtran@ietf.org; Mon, 05 Mar 2007 07:06:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2007 21:06:28 +0900 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GT Routing with NULL(H'0000) PC Thread-Index: AcdfHrRHVm10dqCKRJeDKtLncSlIKg== From: =?ks_c_5601-1987?B?sce1tcf8?= To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sigtran] GT Routing with NULL(H'0000) PC X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Dear, Sir When the following message came to SG, SG can route this message? Sending CLDT Message from ASP to SG (SUA Layer) Destination Address is composed of these parameters. --- Destination Address +Route Indicator : Route on Global Title (1) +Address Indicator - Include GT : True - Include PC : False - Include SSN : True +Global Title - ???????????? (Some Value) (skip detail) +Subsystem number - ? (Some Value) (skip detail) +Point code - Parameter Tag: Point Code (0x8002) - Parameter Length: 8 - Point code: 0 (0x00 00 00 00) <- the focus is this The GT and SSN value is correct. --- I know that the PC value cannot be 0. But with our test results, in some cases, SG can route these messages = (with 0 PC included) to the right Destination. Is these Is that message perfectly wrong? Ps: Thank you very much Brian F. G. Bidulock. _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 05 07:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOC5J-0004qW-P0; Mon, 05 Mar 2007 07:14:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOC5I-0004lx-LV for sigtran@ietf.org; Mon, 05 Mar 2007 07:14:32 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOC5F-0006zB-RC for sigtran@ietf.org; Mon, 05 Mar 2007 07:14:32 -0500 Received: from ns.pigworks.openss7.net (IDENT:MnH9Spc+DLFKYzUlCVFYpY6oj+2Bq9V2@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l25CEPZ22496; Mon, 5 Mar 2007 05:14:25 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l25CEPD13076; Mon, 5 Mar 2007 05:14:25 -0700 Date: Mon, 5 Mar 2007 05:14:24 -0700 From: "Brian F. G. Bidulock" To: =?iso-8859-1?Q?=B1=C7=B5=B5=C7=FC?= Subject: Re: [Sigtran] GT Routing with NULL(H'0000) PC Message-ID: <20070305051423.A13024@openss7.org> Mail-Followup-To: =?iso-8859-1?Q?=B1=C7=B5=B5=C7=FC?= , sigtran@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from monji@inticube.com on Mon, Mar 05, 2007 at 09:06:28PM +0900 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id l25CEPZ22496 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org =B1=C7=B5=B5=C7=FC, =B1=C7=B5=B5=C7=FC wrote: = (Mon, 05 Mar 2007 21:06:28) > Dear, Sir > When the following message came to SG, SG can route this message? >=20 > Sending CLDT Message from ASP to SG (SUA Layer) > Destination Address is composed of these parameters. > --- > Destination Address > +Route Indicator : Route on Global Title (1) > +Address Indicator > - Include GT : True > - Include PC : False It does not really matter what the PC is, with (Include PC : False) it wi= ll not be included in the resulting SCCP message. The SG is welcome to rout= e the message on global title. It would be better form to not include the PC parameter in the message, b= ut the SG can be forgiving if it wants. --brian > - Include SSN : True > +Global Title > - ???????????? (Some Value) (skip detail) > +Subsystem number > - ? (Some Value) (skip detail) > +Point code > - Parameter Tag: Point Code (0x8002) > - Parameter Length: 8 > - Point code: 0 (0x00 00 00 00) <- the focus is this >=20 > The GT and SSN value is correct. > --- >=20 > I know that the PC value cannot be 0. > But with our test results, in some cases, SG can route these messages (= with 0 PC included) to the right Destination. > Is these > Is that message perfectly wrong? >=20 > Ps: Thank you very much Brian F. G. Bidulock. >=20 >=20 > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 05 07:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCUt-0000tP-BD; Mon, 05 Mar 2007 07:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOCUs-0000tK-Ho for sigtran@ietf.org; Mon, 05 Mar 2007 07:40:58 -0500 Received: from [211.179.3.4] (helo=mail.inticube.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOCUp-00040z-1Y for sigtran@ietf.org; Mon, 05 Mar 2007 07:40:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sigtran] GT Routing with NULL(H'0000) PC Date: Mon, 5 Mar 2007 21:40:49 +0900 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sigtran] GT Routing with NULL(H'0000) PC Thread-Index: AcdfH3Rf0BmHmiT/Sm63g7JlMkKougAAcwRA References: <20070305051423.A13024@openss7.org> From: =?utf-8?B?6raM64+E7ZiV?= To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0927240125==" Errors-To: sigtran-bounces@ietf.org --===============0927240125== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFnYWluLg0KSSBjb25mdXNlZCB3aXRoICJSRkMgMzg2OCAvIDMuMTAuMi4yLiAgQWRk cmVzcyBJbmRpY2F0b3IiLg0KIiBGb3IgZXhhbXBsZSwgdGhlIFBDDQogICBwYXJhbWV0ZXIgaXMg cHJlc2VudCBpbiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgQ0xEVCBzZW50IGZyb20N CiAgIEFTUC0+U0csIGJ1dCBiaXQgMiBpcyBzZXQgdG8gIjAiIG1lYW5pbmcgImRvIG5vdCBwb3B1 bGF0ZSB0aGlzIGluIHRoZQ0KICAgU0NDUCBjYWxsZWQgcGFydHkgYWRkcmVzcyIuICBUaGUgZWZm ZWN0IGlzIHRoYXQgdGhlIFNHIG9ubHkgdXNlcyB0aGUNCiAgIFBDIHRvIHBvcHVsYXRlIHRoZSBN VFAgcm91dGluZyBsYWJlbCBEUEMgZmllbGQsIGJ1dCBkb2VzIG5vdCBpbmNsdWRlDQogICBpdCBp biB0aGUgU0NDUCBjYWxsZWQgcGFydHkgYWRkcmVzcy4iDQoNCkFjY29yZGluZyB0byB0aGlzIGV4 YW1wbGUsIHdyb25nIFBDIHZhbHVlIGNhbiBjYXVzZSB3cm9uZyBNVFAgcm91dGluZy4NCkJ1dCBJ IHRob3VnaHQgdGhhdCBTRyBtYXkgZGlzY2FyZCB0aGlzIFBDIHZhbHVlIHdoZW4gU0cgY2Fubm90 IGZpbmQgcmlnaHQgcm91dGUuIEFtIEkgcmlnaHQ/DQoNCkFkZGl0aW9uIHRvIGxhc3QgcXVlc3Rp b24sIHRoZSBTRyBlbmdpbmVlciB0b2xkIG1lIHRoYXQgc29tZSBlcnJvciBtZXNzYWdlcyBsb2dn ZWQgb24gU0cgd2hlbiB0aGF0IG1lc3NhZ2UgKDAgUEMgdmFsdWVkKSBjYW1lIChidXQgSSBoYXZl IG5vdCByZWNlaXZlZCB0aGUgZXhhY3QgZXJyb3IgbWVzc2FnZSkNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRi4gRy4gQmlkdWxvY2sgW21haWx0bzpiaWR1bG9j a0BvcGVuc3M3Lm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDA1LCAyMDA3IDk6MTQgUE0NClRv OiDqtozrj4TtmJUNCkNjOiBzaWd0cmFuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NpZ3RyYW5d IEdUIFJvdXRpbmcgd2l0aCBOVUxMKEgnMDAwMCkgUEMNCg0KwrHDh8K1wrXDh8O8LA0KDQrCscOH wrXCtcOHw7wgd3JvdGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoTW9uLCAwNSBNYXIgMjAwNyAyMTowNjoyOCkN Cj4gRGVhciwgU2lyDQo+IFdoZW4gdGhlIGZvbGxvd2luZyBtZXNzYWdlIGNhbWUgdG8gU0csIFNH IGNhbiByb3V0ZSB0aGlzIG1lc3NhZ2U/DQo+IA0KPiBTZW5kaW5nIENMRFQgTWVzc2FnZSBmcm9t IEFTUCB0byBTRyAoU1VBIExheWVyKQ0KPiBEZXN0aW5hdGlvbiBBZGRyZXNzIGlzIGNvbXBvc2Vk IG9mIHRoZXNlIHBhcmFtZXRlcnMuDQo+IC0tLQ0KPiBEZXN0aW5hdGlvbiBBZGRyZXNzDQo+IAkr Um91dGUgSW5kaWNhdG9yIDogUm91dGUgb24gR2xvYmFsIFRpdGxlICgxKQ0KPiAJK0FkZHJlc3Mg SW5kaWNhdG9yDQo+IAkJLSBJbmNsdWRlIEdUIDogVHJ1ZQ0KPiAJCS0gSW5jbHVkZSBQQyA6IEZh bHNlDQoNCkl0IGRvZXMgbm90IHJlYWxseSBtYXR0ZXIgd2hhdCB0aGUgUEMgaXMsIHdpdGggKElu Y2x1ZGUgUEMgOiBGYWxzZSkgaXQgd2lsbA0Kbm90IGJlIGluY2x1ZGVkIGluIHRoZSByZXN1bHRp bmcgU0NDUCBtZXNzYWdlLiAgVGhlIFNHIGlzIHdlbGNvbWUgdG8gcm91dGUgdGhlDQptZXNzYWdl IG9uIGdsb2JhbCB0aXRsZS4NCg0KSXQgd291bGQgYmUgYmV0dGVyIGZvcm0gdG8gbm90IGluY2x1 ZGUgdGhlIFBDIHBhcmFtZXRlciBpbiB0aGUgbWVzc2FnZSwgYnV0DQp0aGUgU0cgY2FuIGJlIGZv cmdpdmluZyBpZiBpdCB3YW50cy4NCg0KLS1icmlhbg0KDQo+IAkJLSBJbmNsdWRlIFNTTiA6IFRy dWUNCj4gCStHbG9iYWwgVGl0bGUNCj4gCQktID8/Pz8/Pz8/Pz8/PyAoU29tZSBWYWx1ZSkgKHNr aXAgZGV0YWlsKQ0KPiAJK1N1YnN5c3RlbSBudW1iZXINCj4gCQktID8gKFNvbWUgVmFsdWUpIChz a2lwIGRldGFpbCkNCj4gCStQb2ludCBjb2RlDQo+IAkJLSBQYXJhbWV0ZXIgVGFnOiBQb2ludCBD b2RlICgweDgwMDIpDQo+IAkJLSBQYXJhbWV0ZXIgTGVuZ3RoOiA4DQo+IAkJLSBQb2ludCBjb2Rl OiAwICgweDAwIDAwIDAwIDAwKSA8LSB0aGUgZm9jdXMgaXMgdGhpcw0KPiANCj4gVGhlIEdUIGFu ZCBTU04gdmFsdWUgaXMgY29ycmVjdC4NCj4gLS0tDQo+IA0KPiBJIGtub3cgdGhhdCB0aGUgUEMg dmFsdWUgY2Fubm90IGJlIDAuDQo+IEJ1dCB3aXRoIG91ciB0ZXN0IHJlc3VsdHMsIGluIHNvbWUg Y2FzZXMsIFNHIGNhbiByb3V0ZSB0aGVzZSBtZXNzYWdlcyAod2l0aCAwIFBDIGluY2x1ZGVkKSB0 byB0aGUgcmlnaHQgRGVzdGluYXRpb24uDQo+IElzIHRoZXNlDQo+IElzIHRoYXQgbWVzc2FnZSBw ZXJmZWN0bHkgd3Jvbmc/DQo+IA0KPiBQczogVGhhbmsgeW91IHZlcnkgbXVjaCBCcmlhbiBGLiBH LiBCaWR1bG9jay4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBTaWd0cmFuIG1haWxpbmcgbGlzdA0KPiBTaWd0cmFuQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZ3RyYW4NCg0KLS0g DQpCcmlhbiBGLiBHLiBCaWR1bG9jaw0KYmlkdWxvY2tAb3BlbnNzNy5vcmcNCmh0dHA6Ly93d3cu b3BlbnNzNy5vcmcvDQoNCg== --===============0927240125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0927240125==-- From sigtran-bounces@ietf.org Mon Mar 05 10:11:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEqG-0001gL-4Z; Mon, 05 Mar 2007 10:11:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEqE-0001ax-U8 for sigtran@ietf.org; Mon, 05 Mar 2007 10:11:10 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEpr-0004Z0-OM for sigtran@ietf.org; Mon, 05 Mar 2007 10:11:10 -0500 Received: from ns.pigworks.openss7.net (IDENT:hThlx4fkndAPzsz30hj2DJT8fjYNWYsL@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l25FAkZ27043; Mon, 5 Mar 2007 08:10:46 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l25FAkL15645; Mon, 5 Mar 2007 08:10:46 -0700 Date: Mon, 5 Mar 2007 08:10:46 -0700 From: "Brian F. G. Bidulock" To: ??? Subject: Re: [Sigtran] GT Routing with NULL(H'0000) PC Message-ID: <20070305081046.A15393@openss7.org> Mail-Followup-To: ??? , sigtran@ietf.org References: <20070305051423.A13024@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from monji@inticube.com on Mon, Mar 05, 2007 at 09:40:49PM +0900 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id l25FAkZ27043 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org ???, ??? wrote: = (Mon, 05 Mar 2007 21:40:49) > Thanks again. > I confused with "RFC 3868 / 3.10.2.2. Address Indicator". > " For example, the PC > parameter is present in the destination address of the CLDT sent fro= m > ASP->SG, but bit 2 is set to "0" meaning "do not populate this in th= e > SCCP called party address". The effect is that the SG only uses the > PC to populate the MTP routing label DPC field, but does not include > it in the SCCP called party address." >=20 > According to this example, wrong PC value can cause wrong MTP routing. That assumes that the SG itself does not perform GT. > But I thought that SG may discard this PC value when SG cannot find rig= ht route. Am I right? As I said, the SG is welcome to perform routing based on GT and come up w= ith a new PC. --brian >=20 > Addition to last question, the SG engineer told me that some error mess= ages logged on SG when that message (0 PC valued) came (but I have not re= ceived the exact error message) >=20 >=20 > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]=20 > Sent: Monday, March 05, 2007 9:14 PM > To: =EA=B6=8C=EB=8F=84=ED=98=95 > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] GT Routing with NULL(H'0000) PC >=20 > =C2=B1=C3=87=C2=B5=C2=B5=C3=87=C3=BC, >=20 > =C2=B1=C3=87=C2=B5=C2=B5=C3=87=C3=BC wrote: = (Mon, 05 Mar 2007 21:06:28) > > Dear, Sir > > When the following message came to SG, SG can route this message? > >=20 > > Sending CLDT Message from ASP to SG (SUA Layer) > > Destination Address is composed of these parameters. > > --- > > Destination Address > > +Route Indicator : Route on Global Title (1) > > +Address Indicator > > - Include GT : True > > - Include PC : False >=20 > It does not really matter what the PC is, with (Include PC : False) it = will > not be included in the resulting SCCP message. The SG is welcome to ro= ute the > message on global title. >=20 > It would be better form to not include the PC parameter in the message,= but > the SG can be forgiving if it wants. >=20 > --brian >=20 > > - Include SSN : True > > +Global Title > > - ???????????? (Some Value) (skip detail) > > +Subsystem number > > - ? (Some Value) (skip detail) > > +Point code > > - Parameter Tag: Point Code (0x8002) > > - Parameter Length: 8 > > - Point code: 0 (0x00 00 00 00) <- the focus is this > >=20 > > The GT and SSN value is correct. > > --- > >=20 > > I know that the PC value cannot be 0. > > But with our test results, in some cases, SG can route these messages= (with 0 PC included) to the right Destination. > > Is these > > Is that message perfectly wrong? > >=20 > > Ps: Thank you very much Brian F. G. Bidulock. > >=20 > >=20 > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ --=20 Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 05 13:14:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOHh6-0002RA-DG; Mon, 05 Mar 2007 13:13:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOHh5-0002R1-4N for sigtran@ietf.org; Mon, 05 Mar 2007 13:13:55 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOHh2-0007Vp-HL for sigtran@ietf.org; Mon, 05 Mar 2007 13:13:55 -0500 Received: from [192.168.1.2] (p508FC8E2.dip.t-dialin.net [80.143.200.226]) by mail-n.franken.de (Postfix) with ESMTP id 302398006D9B; Mon, 5 Mar 2007 19:13:47 +0100 (CET) (KNF-authenticated sender: macmic) References: <43CEA2D153F88E47B0E3CFE0656B89CEFB3936@Xms1.etsihq.org> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 1 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <71DD395C-F211-4687-BBF3-F04FB4CDD1DD@lurchi.franken.de> Content-Transfer-Encoding: quoted-printable From: Michael Tuexen Date: Mon, 5 Mar 2007 19:12:49 +0100 To: SIGTRAN X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 2.7 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: =?ISO-8859-1?Q?Aur=E9lie_Sfez?= Subject: [Sigtran] Fwd: Invitation to the SIGTRAN Protocol Testing Plugtests Event - 16-20 April 2007 in Moscow - Russia - 2nd reminder X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Dear all, I'm forwarding this reminder... Best regards Michael Begin forwarded message: > From: Aur=E9lie Sfez > Date: March 5, 2007 12:06:40 PM GMT+01:00 > To: "Michael Tuexen_Internet" > Subject: FW: Invitation to the SIGTRAN Protocol Testing Plugtests =20 > Event - 16-20 April 2007 in Moscow - Russia - 2nd reminder > > Dear Mr Tuexen, > > Would you be so kind to forward the 2nd reminder to the sigtran =20 > mailing list ? > > I thank you in advance. > > Best Regards, > > Aurelie Sfez > Plugtests Event Coordinator > Tel: +33 4 92 94 42 95 > Fax: +33 4 92 38 49 14 > http://www.etsi.org/plugtests/calendar.htm > > From: Plugtests > Sent: 05 March 2007 12:03 > Subject: Invitation to the SIGTRAN Protocol Testing Plugtests Event =20= > - 16-20 April 2007 in Moscow - Russia - 2nd reminder > Importance: High > > 2nd Reminder ! > Registration is open until 31st of March 2007. > > Please take into account that you will need a few weeks to obtain =20 > your VISA in order to get to Moscow. Please find all the =20 > information about how to get a VISA under Travel and VISA information. > > > From: Plugtests > Sent: 23 January 2007 17:46 > Subject: Invitation to the SIGTRAN Protocol Testing Plugtests Event =20= > - 16-20 April 2007 in Moscow - Russia > > Dear Madam, > Dear Sir, > > The ETSI=92s PlugtestsTM Service is pleased to invite you to the next =20= > SIGTRAN Interoperability Test Event, which will take place from =20 > 16th to 20th April 2007 at ZNIIS (Russian Central Science Research =20 > Institute) in Moscow. > > ZNIIS possesses interesting facilities which will provide the =20 > community additional value such as SS7 connectivity to address =20 > further SS7-SIGTRAN interoperability after the first experience =20 > gained at the last event. We will also gain valuable knowledge from =20= > their NGN testing experience. > > The SIGTRAN (Protocol Testing) family of protocols (IUA, DUA, V5UA, =20= > M2PA, M2UA, M3UA, SUA) addresses the transport of packet-based PSTN =20= > signaling over IP Networks, taking into account functional and =20 > performance requirements of the PSTN signaling. > This event is an opportunity for engineers from competing =20 > organizations to meet together in a commercially secure =20 > environment, to share experiences and improve interoperability =20 > between their implementations. > Should you be interested, you will be able to retrieve all =20 > information related to this event at the following address: http://=20 > www.etsi.org/plugtests/SIGTRAN.htm > > Registration is open until 31st of March 2007. > > Please take into account that you will need a few weeks to obtain =20 > your VISA in order to get to Moscow. Please find all the =20 > information about how to get a VISA under Travel & VISA information. > > We would be pleased to welcome you to SIGTRAN Protocol Testing =20 > Plugtests Event. > > > Yours faithfully, > > > Philippe Cousin > Interoperability Service Manager > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Wed Mar 07 06:53:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOuhM-0006kv-39; Wed, 07 Mar 2007 06:52:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOuhK-0006kq-Eu for sigtran@ietf.org; Wed, 07 Mar 2007 06:52:46 -0500 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOuhJ-0001RA-7j for sigtran@ietf.org; Wed, 07 Mar 2007 06:52:46 -0500 Received: by wx-out-0506.google.com with SMTP id h31so134647wxd for ; Wed, 07 Mar 2007 03:52:45 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=X/N468ZKeKx6pmZbVMyR/JBXzGbrLjHFD8HB16ovZk0mfeDj7/3dbRDS64YO/rJTPPKqxJydkHiHyb0kIIwMfZlGdNjzDOVg5zdY5/Spqtj1ZIRP+hfxpDp7lVtEjn91Pk1CHxooRnbPmQyhjwuzzVc4P97hOYui1hgf3iaiQmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=BIQokXTBJ4+0spZ+4MuYdzzgpZRXJT6YJ2hI7sHbiOOMt5nRVy3GdB8dam/RqvaK7xwtXW1FhBQK01VBHMTuVkO4hxtENpga0AMA8JYpmAnOpwzc4hJ1IJw7PfFMMOWo4TNi0KxuXTOkM6sE/HvYE5c3+GfgoU2V3CSzvB9bRwY= Received: by 10.90.106.11 with SMTP id e11mr153293agc.1173268365020; Wed, 07 Mar 2007 03:52:45 -0800 (PST) Received: by 10.90.66.19 with HTTP; Wed, 7 Mar 2007 03:52:44 -0800 (PST) Message-ID: Date: Wed, 7 Mar 2007 17:22:45 +0530 From: "Ambika Tripathy" To: sigtran , bidulock MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Sigtran] DPC in REG REQ X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0046214888==" Errors-To: sigtran-bounces@ietf.org --===============0046214888== Content-Type: multipart/alternative; boundary="----=_Part_149102_9342870.1173268364999" ------=_Part_149102_9342870.1173268364999 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Brain, I have one doubt regarding the DPC parameter in the REG REQ message. As per RFC-3332 Destination Point Code: The Destination Point Code parameter is mandatory, and identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. The format is the same as described for the Affected Destination parameter in the DUNA message (See Section 3.4.1). Its format is: Should i think the DPC mean the OPC of the ASP end if the scenario is like below. ASP SG ----------------------------------------- ---------------REG REQ------------> OPC = 2.2.2 OPC = 1.1.1 DPC = 1.1.1 DPC = 2.2.2 Then what will be the DPC value of the REG REQ message from ASP? -- Br, Ambika Prasad Tripathy Nethawk Networks Cell: +91-94375 47730 ------=_Part_149102_9342870.1173268364999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
Hi Brain,
 
       I have one doubt regarding the DPC parameter in the REG REQ message.
As per RFC-3332
 
Destination Point Code:

      The Destination Point Code parameter is mandatory, and identifies
      the Destination Point Code of incoming SS7 traffic for which the
      ASP is registering.  The format is the same as described for the
      Affected Destination parameter in the DUNA message (See Section
      3.4.1).  Its format is:

Should i think the DPC mean the OPC of the ASP end if the scenario is like below.
 
ASP                               SG
-----------------------------------------
---------------REG REQ------------>
OPC = 2.2.2           OPC = 1.1.1
DPC = 1.1.1            DPC = 2.2.2
 
Then what will be the DPC value of the REG REQ message from ASP?
--
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730
------=_Part_149102_9342870.1173268364999-- --===============0046214888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0046214888==-- From sigtran-bounces@ietf.org Wed Mar 07 07:43:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOvUN-0004hQ-KJ; Wed, 07 Mar 2007 07:43:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOvUM-0004Zg-7M for sigtran@ietf.org; Wed, 07 Mar 2007 07:43:26 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOvTS-0005iF-Rx for sigtran@ietf.org; Wed, 07 Mar 2007 07:42:32 -0500 Received: from ns.pigworks.openss7.net (IDENT:Vz8A3Q1a2XlJMqQemEonXXmAXCC7CGHX@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l27CgTZ01926; Wed, 7 Mar 2007 05:42:29 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l27CgT611232; Wed, 7 Mar 2007 05:42:29 -0700 Date: Wed, 7 Mar 2007 05:42:27 -0700 From: "Brian F. G. Bidulock" To: Ambika Tripathy Message-ID: <20070307054227.A11102@openss7.org> Mail-Followup-To: Ambika Tripathy , sigtran References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ambika.tripathy@gmail.com on Wed, Mar 07, 2007 at 05:22:45PM +0530 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sigtran Subject: [Sigtran] Re: DPC in REG REQ X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Ambika, In this case, DPC is used as viewed from the SG. That is, the DPC is the point code in the DPC portion of the MTP Routing Label in messages that the SG will send to the ASP. Therefore, the DPC is the point code belonging to the ASP. (Most things in these RFCs, such as ASP state, is as viewed from the SG). --brian Ambika Tripathy wrote: (Wed, 07 Mar 2007 17:22:45) > > > > Hi Brain, > > > > I have one doubt regarding the DPC parameter in the REG REQ > message. > > As per RFC-3332 > > > > Destination Point Code: > The Destination Point Code parameter is mandatory, and > identifies > the Destination Point Code of incoming SS7 traffic for which the > ASP is registering. The format is the same as described for the > Affected Destination parameter in the DUNA message (See Section > 3.4.1). Its format is: > > Should i think the DPC mean the OPC of the ASP end if the scenario is > like below. > > > > ASP SG > > ----------------------------------------- > > ---------------REG REQ------------> > > OPC = 2.2.2 OPC = 1.1.1 > > DPC = 1.1.1 DPC = 2.2.2 > > > > Then what will be the DPC value of the REG REQ message from ASP? > -- > Br, > Ambika Prasad Tripathy > Nethawk Networks > Cell: +91-94375 47730 -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 08 12:40:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPMav-0007Pi-Se; Thu, 08 Mar 2007 12:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPMau-0007PQ-1u for sigtran@ietf.org; Thu, 08 Mar 2007 12:40:00 -0500 Received: from [202.138.127.180] (helo=RADAGMTA020.ril.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPMak-0003yT-Ee for sigtran@ietf.org; Thu, 08 Mar 2007 12:40:00 -0500 Received: from radagJROUT010.relianceada.com ([10.8.51.88]) by RADAGMTA020.ril.com (8.13.6+Sun/8.12.10) with ESMTP id l27CogVl002516; Wed, 7 Mar 2007 18:20:46 +0530 (IST) In-Reply-To: To: "Ambika Tripathy" Subject: Re: [Sigtran] DPC in REG REQ MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dheeraj.Dubey@relianceada.com Date: Wed, 7 Mar 2007 18:23:56 +0530 X-MIMETrack: Serialize by Router on RADAGJROUT010/SVR/RelianceADA(Release 7.0.2|September 26, 2006) at 03/07/2007 06:19:08 PM, Serialize complete at 03/07/2007 06:19:08 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: bidulock , sigtran X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1621859959==" Errors-To: sigtran-bounces@ietf.org This is a multipart message in MIME format. --===============1621859959== Content-Type: multipart/alternative; boundary="=_alternative 0046493465257297_=" This is a multipart message in MIME format. --=_alternative 0046493465257297_= Content-Type: text/plain; charset="US-ASCII" Hi Ambika, As per my knowledge, REG REQ is used to share Routing Information (in RK parameter) to Remote User. It is just like as the Capabilites Exchages b/w Local and Remote user (useful to take Routing decisions). So, when you send REG REQ to Remote user, you should set your own PC (Local PC or OPC(in your terms)) in DPC parameter of Routing Key. In your Call flow, PC of ASP will be DPC for REG REQ (ASP->SG). --- Dheeraj "Ambika Tripathy" 03/07/2007 05:22 PM To sigtran , bidulock cc Subject [Sigtran] DPC in REG REQ Hi Brain, I have one doubt regarding the DPC parameter in the REG REQ message. As per RFC-3332 Destination Point Code: The Destination Point Code parameter is mandatory, and identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. The format is the same as described for the Affected Destination parameter in the DUNA message (See Section 3.4.1). Its format is: Should i think the DPC mean the OPC of the ASP end if the scenario is like below. ASP SG ----------------------------------------- ---------------REG REQ------------> OPC = 2.2.2 OPC = 1.1.1 DPC = 1.1.1 DPC = 2.2.2 Then what will be the DPC value of the REG REQ message from ASP? -- Br, Ambika Prasad Tripathy Nethawk Networks Cell: +91-94375 47730 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --=_alternative 0046493465257297_= Content-Type: text/html; charset="US-ASCII"

Hi Ambika,

As per my knowledge, REG REQ is used to share Routing Information (in RK parameter) to Remote User. It is just like as the Capabilites Exchages b/w Local and Remote user (useful to take Routing decisions). So, when you send REG REQ to Remote user, you should set  your own PC (Local PC or OPC(in your terms)) in DPC parameter of Routing Key.


In your Call flow, PC of ASP will be DPC for REG REQ (ASP->SG).

--- Dheeraj



"Ambika Tripathy" <ambika.tripathy@gmail.com>

03/07/2007 05:22 PM

To
sigtran <sigtran@ietf.org>, bidulock <bidulock@openss7.org>
cc
Subject
[Sigtran] DPC in REG REQ





 
Hi Brain,
 
       I have one doubt regarding the DPC parameter in the REG REQ message.
As per RFC-3332
 
Destination Point Code:

     The Destination Point Code parameter is mandatory, and identifies
     the Destination Point Code of incoming SS7 traffic for which the
     ASP is registering.  The format is the same as described for the
     Affected Destination parameter in the DUNA message (See Section
     3.4.1).  Its format is:
Should i think the DPC mean the OPC of the ASP end if the scenario is like below.
 
ASP                               SG
-----------------------------------------
---------------REG REQ------------>
OPC = 2.2.2           OPC = 1.1.1
DPC = 1.1.1            DPC = 2.2.2
 
Then what will be the DPC value of the REG REQ message from ASP?
--
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730 _______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran
--=_alternative 0046493465257297_=-- --===============1621859959== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1621859959==-- From sigtran-bounces@ietf.org Sun Mar 11 21:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQZlN-0005vm-PK; Sun, 11 Mar 2007 21:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQZlL-0005ve-TV for sigtran@ietf.org; Sun, 11 Mar 2007 21:55:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQZlK-0003OM-Li for sigtran@ietf.org; Sun, 11 Mar 2007 21:55:47 -0400 Received: (qmail invoked by alias); 12 Mar 2007 01:55:45 -0000 Received: from leer-d9bbdaa4.pool.mediaWays.net (EHLO [192.168.2.33]) [217.187.218.164] by mail.gmx.net (mp002) with SMTP; 12 Mar 2007 02:55:45 +0100 X-Authenticated: #5315833 X-Provags-ID: V01U2FsdGVkX1+wd6dENAqwx3HmPwimTe6HweD6kNWZEFJkVNmyM1 orT/2sHaN48DUp Message-ID: <45F4B321.90808@gmx.de> Date: Mon, 12 Mar 2007 02:55:45 +0100 From: pavel User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: sigtran@ietf.org Subject: Re: [Sigtran] Changeover M3UA-M2PA References: <45DDB01C.7060909@gmx.de> <20070222111910.A7215@openss7.org> <45E1B744.5060404@gmx.de> <20070225163428.A7923@openss7.org> In-Reply-To: <20070225163428.A7923@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi, Exists limitation of maximum association numbers per bandwidth? If yes, how can this be calculate? Regards, Pavel _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 12 00:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQcIH-0001Jj-Vk; Mon, 12 Mar 2007 00:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQcIG-0001Di-34 for sigtran@ietf.org; Mon, 12 Mar 2007 00:37:56 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQcIE-0003rv-L8 for sigtran@ietf.org; Mon, 12 Mar 2007 00:37:56 -0400 Received: from ns.pigworks.openss7.net (IDENT:7Li3hc56FAYfrS+K388kadVSsL5SUh8V@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2C4bpZ20395; Sun, 11 Mar 2007 21:37:51 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2C4bp505408; Sun, 11 Mar 2007 21:37:51 -0700 Date: Sun, 11 Mar 2007 22:37:51 -0600 From: "Brian F. G. Bidulock" To: pavel Subject: Re: [Sigtran] Changeover M3UA-M2PA Message-ID: <20070311223751.A5348@openss7.org> Mail-Followup-To: pavel , sigtran@ietf.org References: <45DDB01C.7060909@gmx.de> <20070222111910.A7215@openss7.org> <45E1B744.5060404@gmx.de> <20070225163428.A7923@openss7.org> <45F4B321.90808@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45F4B321.90808@gmx.de>; from pavel.paul@gmx.de on Mon, Mar 12, 2007 at 02:55:45AM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org pavel, There is no hard limit to the number of associations for a given bandwidth. --brian pavel wrote: (Mon, 12 Mar 2007 02:55:45) > Hi, > > Exists limitation of maximum association numbers per bandwidth? > If yes, how can this be calculate? > > Regards, > Pavel > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 12 12:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnCq-0003v0-AD; Mon, 12 Mar 2007 12:17:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQnCp-0003uk-BP for sigtran@ietf.org; Mon, 12 Mar 2007 12:17:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQnCn-0004uK-Tu for sigtran@ietf.org; Mon, 12 Mar 2007 12:17:03 -0400 Received: (qmail invoked by alias); 12 Mar 2007 16:17:01 -0000 Received: from leer-d9bbd9a4.pool.mediaWays.net (EHLO [192.168.2.33]) [217.187.217.164] by mail.gmx.net (mp036) with SMTP; 12 Mar 2007 17:17:01 +0100 X-Authenticated: #5315833 X-Provags-ID: V01U2FsdGVkX1/oWJNkwFLo7FGkrEZ3EhtDivywMBgIG/MzTYugBy Q4biHIeGXjF+X3 Message-ID: <45F57CF5.4070909@gmx.de> Date: Mon, 12 Mar 2007 17:16:53 +0100 From: pavel User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bidulock@openss7.org Subject: Re: [Sigtran] Changeover M3UA-M2PA References: <45DDB01C.7060909@gmx.de> <20070222111910.A7215@openss7.org> <45E1B744.5060404@gmx.de> <20070225163428.A7923@openss7.org> <45F4B321.90808@gmx.de> <20070311223751.A5348@openss7.org> In-Reply-To: <20070311223751.A5348@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Brian, Which recommendation exists for maximum association numbers by use 2Mbit/s bandwidth? Or is it experience values as regards of application? Regards, Pavel Brian F. G. Bidulock schrieb: > pavel, > > There is no hard limit to the number of associations for a given > bandwidth. > > --brian > > pavel wrote: (Mon, 12 Mar 2007 02:55:45) > >> Hi, >> >> Exists limitation of maximum association numbers per bandwidth? >> If yes, how can this be calculate? >> >> Regards, >> Pavel >> >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran >> > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Mar 13 07:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR54h-0005oS-T3; Tue, 13 Mar 2007 07:21:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR54h-0005oK-AQ for sigtran@ietf.org; Tue, 13 Mar 2007 07:21:51 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR54d-0005NB-PD for sigtran@ietf.org; Tue, 13 Mar 2007 07:21:51 -0400 Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 2A59B346708 for ; Tue, 13 Mar 2007 04:21:45 -0700 (PDT) Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203]) by smtp.ccpu.com (Postfix) with ESMTP id 1CF0D346704 for ; Tue, 13 Mar 2007 04:21:45 -0700 (PDT) Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 04:21:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Mar 2007 16:51:04 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F0C93E87@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: USE of RC Thread-Index: AcdlYbBohfXvtE+OSe2jpz5d2gsW5Q== From: "Salil Agrawal" To: X-OriginalArrivalTime: 13 Mar 2007 11:21:43.0481 (UTC) FILETIME=[C7642290:01C76561] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Sigtran] USE of RC X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1401359403==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1401359403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76561.C48B8189" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76561.C48B8189 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 Just want to understand the use of the RC parameter in SUA or M3UA, what could be the possible problems if there is no RC parameter.=20 =20 Thanks, Salil =20 ------_=_NextPart_001_01C76561.C48B8189 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Just want to understand the use of the RC parameter in SUA or M3UA, what = could be the possible problems if there is no RC parameter. =

 

Thanks,

Salil

 

------_=_NextPart_001_01C76561.C48B8189-- --===============1401359403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1401359403==-- From sigtran-bounces@ietf.org Tue Mar 13 09:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7B4-0000n5-Kw; Tue, 13 Mar 2007 09:36:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7B4-0000my-8v for sigtran@ietf.org; Tue, 13 Mar 2007 09:36:34 -0400 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR7Az-0003iY-Gq for sigtran@ietf.org; Tue, 13 Mar 2007 09:36:34 -0400 Received: by an-out-0708.google.com with SMTP id d30so1895728and for ; Tue, 13 Mar 2007 06:36:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=scO1e0qAf8kmj+bdAEyWhNv8VT+3BKedBUvXNZ83HkuYPrX73Idv/xPPMNkxCxykwabhPjDw7qYvVQK3nbGzTZasRu0aFrK1Eq6bkNh+wdTakKjm38y19zmX7DfdyTJi6xas+IMz4hckXQG5ESmVaD4byGaXyd1w5lWdxXRH2YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IPOE8TMstVqzERJ8ttgszUuuNK57DFlBXXxjamRGBTwOrq37qWn32U9Eo9gw/2g6+M47q5REAqsPdzp4VWdT8vt0BIk3EHNqYaSZ88CyUfxbJjCgT5F8rs8t+P732y/dLCh8sBOGtDVw5znCLBFD4pmwAAr0Yabgma8boEARPu4= Received: by 10.100.43.9 with SMTP id q9mr741142anq.1173792987663; Tue, 13 Mar 2007 06:36:27 -0700 (PDT) Received: by 10.100.154.2 with HTTP; Tue, 13 Mar 2007 06:36:27 -0700 (PDT) Message-ID: <6dbbbf160703130636o441c95f6yedbb921eb050695d@mail.gmail.com> Date: Tue, 13 Mar 2007 13:36:27 +0000 From: "Ankit Kumar Sharma" To: "Salil Agrawal" Subject: Re: [Sigtran] USE of RC In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F0C93E87@in-exchange> MIME-Version: 1.0 References: <22F058C3ED9D784E90CE473F2A9847F0C93E87@in-exchange> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1614070731==" Errors-To: sigtran-bounces@ietf.org --===============1614070731== Content-Type: multipart/alternative; boundary="----=_Part_24769_25728613.1173792987629" ------=_Part_24769_25728613.1173792987629 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/13/07, Salil Agrawal wrote: > > Hi, > > > > Just want to understand the use of the RC parameter in SUA or M3UA, what > could be the possible problems if there is no RC parameter. > If an ASP is serving only one AS then RC is not relevent, otherwise routing context is used to identify set of messages corresponding to a particular AS served by an ASP. Thanks, > > Salil > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > ------=_Part_24769_25728613.1173792987629 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 3/13/07, Salil Agrawal <salil.agrawal@ccpu.com> wrote:

Hi,

 

Just want to understand the use of the RC parameter in SUA or M3UA, what could be the possible problems if there is no RC parameter.


If an ASP is serving only one AS then RC is not relevent, otherwise routing context is used to identify set of messages corresponding to a particular AS served by an ASP.

Thanks,

Salil

 


_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran


------=_Part_24769_25728613.1173792987629-- --===============1614070731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1614070731==-- From sigtran-bounces@ietf.org Tue Mar 13 09:45:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7JR-0006Js-5f; Tue, 13 Mar 2007 09:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7JP-0006JT-FH for sigtran@ietf.org; Tue, 13 Mar 2007 09:45:11 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR7JG-0005xY-7C for sigtran@ietf.org; Tue, 13 Mar 2007 09:45:11 -0400 Received: by nf-out-0910.google.com with SMTP id l36so2679874nfa for ; Tue, 13 Mar 2007 06:45:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=c0rJdPfnXjUEqtp3YFmLwHdN4ZRKFNDzOJWpHmLx+60sBKk/YX2/aH8u1zWV/i6/kCs/kmCSk3KJ/ETjBRPCRUAuAEWTkzlaiQpdcGN5FenD/v/V19gUVkEhOYAC8VPchr89VW02aKH3P8h+sTGa9kQD6U3DXSqxpb1HZXzjZ2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ec8atOqEAYuBwQzT0++mm4hh+gCeCc+NlpBaBSrsXFYTeEb/hP+DrhjYAV6IVDabCPU91tBuuvg8G1Bfw7T8uLdp8QlakYp2qrhiv0pOs+hxk6c51L0lPXPwBNB1HagXJh6F2DbQbqlC5LOC9/1EEO98CK23VZ0Ii/kKUyBqKZ8= Received: by 10.78.185.16 with SMTP id i16mr316013huf.1173793501158; Tue, 13 Mar 2007 06:45:01 -0700 (PDT) Received: by 10.78.136.10 with HTTP; Tue, 13 Mar 2007 06:45:01 -0700 (PDT) Message-ID: Date: Tue, 13 Mar 2007 19:15:01 +0530 From: "Ambika Tripathy" To: "Salil Agrawal" Subject: Re: [Sigtran] USE of RC In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F0C93E87@in-exchange> MIME-Version: 1.0 References: <22F058C3ED9D784E90CE473F2A9847F0C93E87@in-exchange> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0941378137==" Errors-To: sigtran-bounces@ietf.org --===============0941378137== Content-Type: multipart/alternative; boundary="----=_Part_12475_26057586.1173793501128" ------=_Part_12475_26057586.1173793501128 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, One ASP can server more that one AS at the same time. to identify the the perticular AS for which the incomming traffic is for, ASP uses RC. +---------------------+ | AS1 | +--------------------------+ -------RC1-------+---------------------+ | ASP | +--------------------------+--------RC2-------+----------------------+ | AS2 | +----------------------+ If there is only one AS for ASP there is no need of RC. -- Br, Ambika Prasad Tripathy Nethawk Networks Cell: +91-94375 47730 On 3/13/07, Salil Agrawal wrote: > > Hi, > > > > Just want to understand the use of the RC parameter in SUA or M3UA, what > could be the possible problems if there is no RC parameter. > > > > Thanks, > > Salil > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > ------=_Part_12475_26057586.1173793501128 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
 
Hi, 
  
 
      One ASP can server more that one AS at the same time. to identify the the perticular AS for which the incomming traffic is for, ASP uses RC.
 
                                                   +---------------------+
                                                    |       AS1         |
+--------------------------+ -------RC1-------+---------------------+
|           ASP          |
+--------------------------+--------RC2-------+----------------------+
                                                    |        AS2         |
                                                   +----------------------+
 
 
      If there is only one AS for ASP there is no need of RC.
 
 
--
Br,
Ambika Prasad Tripathy
Nethawk Networks
Cell: +91-94375 47730

 
On 3/13/07, Salil Agrawal <salil.agrawal@ccpu.com> wrote:

Hi,

 

Just want to understand the use of the RC parameter in SUA or M3UA, what could be the possible problems if there is no RC parameter.

 

Thanks,

Salil

 


_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran




------=_Part_12475_26057586.1173793501128-- --===============0941378137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0941378137==-- From sigtran-bounces@ietf.org Mon Mar 19 13:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLIV-00080G-8A; Mon, 19 Mar 2007 13:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLIU-000804-TG for sigtran@ietf.org; Mon, 19 Mar 2007 13:05:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLIL-0003zM-R2 for sigtran@ietf.org; Mon, 19 Mar 2007 13:05:26 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B564212D9 for ; Mon, 19 Mar 2007 18:05:17 +0100 (CET) X-AuditID: c1b4fb3e-b01efbb0000061ca-2b-45fec2cd98ff Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4A96421106 for ; Mon, 19 Mar 2007 18:05:17 +0100 (CET) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 18:05:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2007 18:05:14 +0100 Message-ID: <4195E435D262F94BB7847A77D8920BB1CF05A2@esealmw114.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ASP vs IPSP Thread-Index: AcdqSMSlwQVCXEfmSaKkedeaMfovfQ== From: "Philippe Huvet I \(MA/ESF\)" To: X-OriginalArrivalTime: 19 Mar 2007 17:05:16.0724 (UTC) FILETIME=[C451E740:01C76A48] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.9 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sigtran] ASP vs IPSP X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hello Sigtran forum, In RFC3332, it exists the following diagram: ****************************************************************** 1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP ******** SS7 ***************** IP ******** * SEP *---------* *--------* * * or * * SGP * * ASP * * STP * * * * * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP-| | SCCP | | SCCP-| | User | +---------------+ | User | +------+ | _____ | +------+ | SCCP | | | | | | SCCP | +------+ +------+-+------+ +------+ | MTP3 | | MTP3 | | M3UA | | M3UA | +------| +------+ +------+ +------+ | MTP2 | | MTP2 | | SCTP | | SCTP | +------+ +------+ +------+ +------+ | L1 | | L1 | | IP | | IP | +------+ +------+ +------+ +------+ |_______________| |______________| ******************************************************************* Does it make any sense to put it this way ? ******** SS7 ***************** IP ******** * SEP *---------* * *--------* * * or * * SEP * IPSP * * IPSP * * STP * * * * * * ******** ***************** ******** +------+ +---------------+ +------+ | SCCP-| | SCCP | | SCCP-| | User | +---------------+ | User | +------+ | _____ | +------+ | SCCP | | | | | | SCCP | +------+ +------+-+------+ +------+ | MTP3 | | MTP3 | | M3UA | | M3UA | +------| +------+ +------+ +------+ | MTP2 | | MTP2 | | SCTP | | SCTP | +------+ +------+ +------+ +------+ | L1 | | L1 | | IP | | IP | +------+ +------+ +------+ +------+ |_______________| |______________| _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 19 13:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLW7-0004wG-Vj; Mon, 19 Mar 2007 13:19:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLW6-0004tA-Db for sigtran@ietf.org; Mon, 19 Mar 2007 13:19:30 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLVk-0005cK-6E for sigtran@ietf.org; Mon, 19 Mar 2007 13:19:30 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 25AF256BB6 for ; Mon, 19 Mar 2007 12:18:51 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l2JHIp5O029788 for ; Mon, 19 Mar 2007 13:18:51 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sigtran] ASP vs IPSP Date: Mon, 19 Mar 2007 12:13:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <4195E435D262F94BB7847A77D8920BB1CF05A2@esealmw114.eemea.ericsson.se> Importance: Normal Received-SPF: none X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Philippe, I don't know whether it would make sense but I guess it is a possibility. The only change I would suggest in your diagram would be an interworking application on top of SEP and IPSP to bridge the two sides. Basically, this would be "proxying" SS7 nodes in IP domain and vice versa. One could think that in the first diagram the interworking happens on signalling layer whereas for the second one it is more on application layer. Thanks, Tolga > -----Original Message----- > From: Philippe Huvet I (MA/ESF) [mailto:philippe.i.huvet@ericsson.com] > Sent: Monday, March 19, 2007 12:05 PM > To: sigtran@ietf.org > Subject: [Sigtran] ASP vs IPSP > > > Hello Sigtran forum, > > In RFC3332, it exists the following diagram: > > ****************************************************************** > 1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP > > ******** SS7 ***************** IP ******** > * SEP *---------* *--------* * > * or * * SGP * * ASP * > * STP * * * * * > ******** ***************** ******** > > +------+ +---------------+ +------+ > | SCCP-| | SCCP | | SCCP-| > | User | +---------------+ | User | > +------+ | _____ | +------+ > | SCCP | | | | | | SCCP | > +------+ +------+-+------+ +------+ > | MTP3 | | MTP3 | | M3UA | | M3UA | > +------| +------+ +------+ +------+ > | MTP2 | | MTP2 | | SCTP | | SCTP | > +------+ +------+ +------+ +------+ > | L1 | | L1 | | IP | | IP | > +------+ +------+ +------+ +------+ > |_______________| |______________| > > ******************************************************************* > > Does it make any sense to put it this way ? > > > ******** SS7 ***************** IP ******** > * SEP *---------* * *--------* * > * or * * SEP * IPSP * * IPSP * > * STP * * * * * * > ******** ***************** ******** > > +------+ +---------------+ +------+ > | SCCP-| | SCCP | | SCCP-| > | User | +---------------+ | User | > +------+ | _____ | +------+ > | SCCP | | | | | | SCCP | > +------+ +------+-+------+ +------+ > | MTP3 | | MTP3 | | M3UA | | M3UA | > +------| +------+ +------+ +------+ > | MTP2 | | MTP2 | | SCTP | | SCTP | > +------+ +------+ +------+ +------+ > | L1 | | L1 | | IP | | IP | > +------+ +------+ +------+ +------+ > |_______________| |______________| > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Mon Mar 19 13:54:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM3E-0002Fq-9e; Mon, 19 Mar 2007 13:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM3C-0002Fj-Qp for sigtran@ietf.org; Mon, 19 Mar 2007 13:53:42 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTM3B-0001QU-4z for sigtran@ietf.org; Mon, 19 Mar 2007 13:53:42 -0400 Received: from ns.pigworks.openss7.net (IDENT:DrQCon16nWTUOUgJksbxpmiBO57oNFMe@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2JHras26700; Mon, 19 Mar 2007 11:53:36 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2JHrWq04576; Mon, 19 Mar 2007 11:53:32 -0600 Date: Mon, 19 Mar 2007 11:53:32 -0600 From: "Brian F. G. Bidulock" To: "Philippe Huvet I (MA/ESF)" Subject: Re: [Sigtran] ASP vs IPSP Message-ID: <20070319115332.A4392@openss7.org> Mail-Followup-To: "Philippe Huvet I (MA/ESF)" , sigtran@ietf.org References: <4195E435D262F94BB7847A77D8920BB1CF05A2@esealmw114.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4195E435D262F94BB7847A77D8920BB1CF05A2@esealmw114.eemea.ericsson.se>; from philippe.i.huvet@ericsson.com on Mon, Mar 19, 2007 at 06:05:14PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Philippe, Philippe Huvet I (MA/ESF) wrote: (Mon, 19 Mar 2007 18:05:14) > Hello Sigtran forum, > > In RFC3332, it exists the following diagram: > RFC 3332 is obsolete. > > ******************************************************************* > > Does it make any sense to put it this way ? > No it does not: under M3UA, IPSP is point to point only and an IPSP does not connect with an SS7 network, so the entire left side of the diagram is incorrect. --brian > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 22 11:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPUf-000723-Se; Thu, 22 Mar 2007 11:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPUd-00071W-SL for Sigtran@ietf.org; Thu, 22 Mar 2007 11:46:24 -0400 Received: from web37414.mail.mud.yahoo.com ([209.191.91.146]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUPUG-0007XZ-28 for Sigtran@ietf.org; Thu, 22 Mar 2007 11:46:23 -0400 Received: (qmail 3038 invoked by uid 60001); 22 Mar 2007 15:45:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fv27w64KYH2Oxrbz7D/qNAUSjV5pcSj0BwsSyOQizV7C4WnN9BVHnat94UvEmxRW6ab4IYq0bqb3j0PGxjKNGwWTHwYww3Blo6eYLG/iZcAzxnNBqRvESPI87NWG/AIKjMatUyVOh2JTgpay5OVwB89NLlkvAQa7LUTu2s1VmYY=; X-YMail-OSG: J64dWDsVM1mdS.IMqiJZq4K9tWkD08X9VQR2JnG60ydqAo1wbLn3Sk0WUPEwDWsFgJKBIHdAeN.6x.wqSpMyWjWXd.98NtpBMA1ONXWt2M_ORIQZ13x1C.5RBPZVke6e Received: from [203.187.132.67] by web37414.mail.mud.yahoo.com via HTTP; Thu, 22 Mar 2007 08:45:59 PDT X-Mailer: YahooMailRC/476 YahooMailWebService/0.7.41.8 Date: Thu, 22 Mar 2007 08:45:59 -0700 (PDT) From: ash kat Subject: Re: [Tsvwg] Re: [Sigtran] SCTP: Heartbeat ack recieved without sending Heartbeat To: Randall Stewart MIME-Version: 1.0 Message-ID: <413963.1035.qm@web37414.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: bidulock@openss7.org, Sigtran@ietf.org, tsvwg@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1509182510==" Errors-To: sigtran-bounces@ietf.org --===============1509182510== Content-Type: multipart/alternative; boundary="0-270763091-1174578359=:1035" --0-270763091-1174578359=:1035 Content-Type: text/plain; charset=ascii Hello Randall Stewart: This is regarding the scenario where the HB-ACK is received without sending a HB. I was expecting something regarding this discussion in the draft-ietf-tsvwg-2960bis-03. Please let me know if we have any plans to include a solution for the discussed scenario. Regards Ashwani Kathuria www.aricent.com ----- Original Message ---- From: Randall Stewart To: ash kat Cc: bidulock@openss7.org; Sigtran@ietf.org; tsvwg@ietf.org Sent: Monday, June 19, 2006 6:28:20 PM Subject: Re: [Tsvwg] Re: [Sigtran] SCTP: Heartbeat ack recieved without sending Heartbeat Ash: I don't remember the stuff being removed... the nonce stuff came in roughly in rev-10 of the I-G.. if I remember right.. might have been 11.. But in any event it SHOULD say to discard a HB-ACK that has an incorrect nonce.. i.e. you ignore it dropping it silently.. Since if you get this, it most likely is an attacker trying to get you to "CONFIRM" an address that it does not own.. I will add this as a todo.. for the next pass of the BIS.. this is obviously either, as Brian points out, a place where we accidentally removed the text... or an oversight.. in either case both sides of what to do should be spelled out.. aka if you receive one and it matches the address is confirmed.. if you receive one and it does NOT match.. silently discard the HB-ACK... Note, that if it is an attacker, most likely you will be shortly receiving an ABORT() or ICMP-Protocol-Not-Available (assuming of course ICMP is not screened out by a firewall :0) R ash kat wrote: > Hi > > IMO there can be 3 possible solutions to this problem: > > 1. The Endpoint should drop/discard the Heartbeat ack chunk > 2. Process the Heartbeat ack as normal. > 3. Send an Abort to peer. > > If we take the: > 3) Third option [Sending the ABORT chunk] : The received HB-ACK is for a valid association but the receiver hasn't sent the HB so this HB-Ack can be from an attacker. So sending an ABORT will close [ABORT] the right association and will solve the purpose of the attacker. So this option is ruled out. > > 2) Second option [Process the Heartbeat Ack as normal ] : Doing this will result in the modification of some internal parameters of the SCTP stack for that association. So this option is also ruled out. > > 1) So the remaining option of silently Discarding/Droping this HB-Ack [without informing the peer or user] is the most appropriate one. > > Please share your view on this? > > Brian: If you remember then please mention what was the behavior for this scenario in the IG that is now removed. It willl help us to make a proper solution for this problem. > > Regards, > Ashwani Kathuria > > "Brian F. G. Bidulock" wrote: > ash, > > ash kat wrote: (Sun, 18 Jun 2006 23:14:09) > >>But there should be some standardized behavior [Whatever it will be as >>a result of this discussion] for this scenario. >> >>Please let me know your opinion about this. > > > At one time there was some (more) mention of this in the I-G (which became > RFC 4460) because at early interops hacking the other implementation's HB > was a popular passtime, however, it was removed at some point along the way > (I'm not sure why). > > IMO there should be some mention, as a hacked HB-ACK could cause an > implementation to overrun its congestion window, posing both a security risk > as well as a risk to the Internet. > > --brian > -- Randall Stewart 803-345-0369 815-342-5222(cell) ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ --0-270763091-1174578359=:1035 Content-Type: text/html; charset=ascii
Hello Randall Stewart:
 
This is regarding the scenario where the HB-ACK is received without sending a HB.
I was expecting something regarding this discussion in the draft-ietf-tsvwg-2960bis-03.
 
Please let me know if we have any plans to include a solution for the discussed scenario.
 
Regards
Ashwani Kathuria
----- Original Message ----
From: Randall Stewart <randall@lakerest.net>
To: ash kat <ashwani_groups@yahoo.com>
Cc: bidulock@openss7.org; Sigtran@ietf.org; tsvwg@ietf.org
Sent: Monday, June 19, 2006 6:28:20 PM
Subject: Re: [Tsvwg] Re: [Sigtran] SCTP: Heartbeat ack recieved without sending Heartbeat

Ash:

I don't remember the stuff being removed... the nonce stuff
came in roughly in rev-10 of the I-G.. if I remember
right.. might have been 11..

But in any event it SHOULD say to discard a HB-ACK
that has an incorrect nonce..

i.e. you ignore it dropping it silently..

Since if you get this, it most likely is an attacker
trying to get you to "CONFIRM" an address that it
does not own..

I will add this as a todo.. for the next pass of the
BIS.. this is obviously either, as Brian points out, a
place where we accidentally removed the text... or an
oversight.. in either case both sides of what to do should
be spelled out.. aka if you receive one and it matches
the address is confirmed.. if you receive one and it
does NOT match.. silently discard the HB-ACK...

Note, that if it is an attacker, most likely you will be
shortly receiving an ABORT() or ICMP-Protocol-Not-Available
(assuming of course ICMP is not screened out by a firewall :0)

R

ash kat wrote:
> Hi
>    
>   IMO there can be 3 possible solutions to this problem:
>    
>   1. The Endpoint should drop/discard the Heartbeat ack chunk
>   2. Process the Heartbeat ack as normal.
>   3. Send an Abort to peer.
>    
>   If we take the:
>   3) Third option [Sending the ABORT chunk] : The received HB-ACK is for a valid association but the receiver hasn't sent the HB so this HB-Ack can be from an attacker. So sending an ABORT will close [ABORT] the right association and will solve the purpose of the attacker. So this option is ruled out.
>
>   2) Second option [Process the Heartbeat Ack as normal ] : Doing this will result in the modification of some internal parameters of the SCTP stack for that association. So this option is also ruled out.
>    
>   1) So the remaining option of silently Discarding/Droping this HB-Ack [without informing the peer or user] is the most appropriate one.
>    
>   Please share your view on this?
>    
>   Brian: If you remember then please mention what was the behavior for this scenario in the IG that is now removed. It willl help us to make a proper solution for this problem.
>    
>   Regards,
>   Ashwani Kathuria
>    
>   "Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
>   ash,
>
> ash kat wrote: (Sun, 18 Jun 2006 23:14:09)
>
>>But there should be some standardized behavior [Whatever it will be as
>>a result of this discussion] for this scenario.
>>
>>Please let me know your opinion about this.
>
>
> At one time there was some (more) mention of this in the I-G (which became
> RFC 4460) because at early interops hacking the other implementation's HB
> was a popular passtime, however, it was removed at some point along the way
> (I'm not sure why).
>
> IMO there should be some mention, as a hacked HB-ACK could cause an
> implementation to overrun its congestion window, posing both a security risk
> as well as a risk to the Internet.
>
> --brian
>


--
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)


It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar. --0-270763091-1174578359=:1035-- --===============1509182510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1509182510==-- From sigtran-bounces@ietf.org Fri Mar 23 01:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUbzG-0003Z5-Hp; Fri, 23 Mar 2007 01:06:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUbzF-0003Yy-1P for sigtran@ietf.org; Fri, 23 Mar 2007 01:06:49 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUbzA-0007qk-Jz for sigtran@ietf.org; Fri, 23 Mar 2007 01:06:49 -0400 Received: from ns.pigworks.openss7.net (IDENT:AxOOXf0h/ZV2b2aChOyKlK19hspX7ZYW@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2N56Us00610; Thu, 22 Mar 2007 23:06:30 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2N56UT29665; Thu, 22 Mar 2007 23:06:30 -0600 Date: Thu, 22 Mar 2007 23:06:30 -0600 From: "Brian F. G. Bidulock" To: sigtran@ietf.org Message-ID: <20070322230630.A29498@openss7.org> Mail-Followup-To: sigtran@ietf.org References: <20070316035729.A12167@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from chen.puran@zte.com.cn on Fri, Mar 23, 2007 at 10:08:39AM +0800 Organization: http://www.openss7.org/ Dsn-Notification-To: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gw.openss7.com id l2N56Us00610 X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Sigtran] Re: Important h248's Message is Discarded by m3ua. X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org chen, If the ASP indeed receives the ASP Active Ack before the M3UA data, it is incorrect for the ASP to reject the message. If it were merely a processing delay, the ASP should not process data messages (or any other message) for the RC while processing the ASP Active Ack message. However, if the ASP Active Ack and the M3UA data are sent on different SCTP streams, it may be that the M3UA data is being processed by the ASP before the ASP Active Ack. Check the stream id of the messages. It is good practise for the SGP to send ASP Active Ack on the same stream that it sends data for the RC so that the M3UA data does not race with the ASP Active Ack. If it does not and it sends data on one stream immediately after the ASP Active Ack was sent on another stream, the M3UA data can always arrive first. --brian On Fri, 23 Mar 2007, chen wrote: > dear sir: >=20 > fter SGP sends the asp active ack message, user layer will send data > message at once.But at ASP,the asp active ack message is being proceedi= ng > and asp is in inactive status when it receives the data message.The dat= a > message is diacarded and an error is sent to SGP. > Is the discarding the message acceptable? How to avoid that this situat= ion > occurs? >=20 > SGP ASP > | | > (inactive)|<------------ASP active--------|(inactive) > | | > (active) |---------ASP active Ack------->| > | |(process,inactive) > |-----------M3UA data---------->| > | | >=20 >=20 >=20 >=20 --=20 Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6 bidulock@openss7.org =A6 world; the unreasonable one persists in =A6 http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6 =A6 Therefore all progress depends on the =A6 =A6 unreasonable man. -- George Bernard Shaw =A6 _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Tue Mar 27 04:24:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW6xB-0002my-Ha; Tue, 27 Mar 2007 04:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW6x9-0002mq-Li for sigtran@ietf.org; Tue, 27 Mar 2007 04:22:51 -0400 Received: from web30006.mail.mud.yahoo.com ([209.191.69.23]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HW6x5-00013F-5N for sigtran@ietf.org; Tue, 27 Mar 2007 04:22:51 -0400 Received: (qmail 70562 invoked by uid 60001); 27 Mar 2007 08:22:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=fVla3o24fnW+MECMWx/rn8F0IJbuZ25rCZjAlxTJMGU8cBe6rIg+M1UZ00AF4JdNvtnaCzvdTCpNRlgAPyELjksfEXuZzVSV3ZuAuPv9rFVo2oh+4gNWPuoU6WtToBMOoURDY5KIcPL91cPoxt9g90H20YfCNsgzGyEaoFrL95o=; X-YMail-OSG: 1yjAS9sVM1lCojNic8t5aa1Dprpn7VTc_Byoty1LA53RwvnhBRGK1pUnQ3SZPCilAclU.pfKYnCytdkKgw.sN2rmCVJygethcMLsMRjvzzR3pE5cM1UKab8szFdonw-- Received: from [195.29.145.167] by web30006.mail.mud.yahoo.com via HTTP; Tue, 27 Mar 2007 01:22:46 PDT Date: Tue, 27 Mar 2007 01:22:46 -0700 (PDT) From: Dario Filjar To: sigtran@ietf.org MIME-Version: 1.0 Message-ID: <588065.70174.qm@web30006.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sigtran] Notify procedure X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385258451==" Errors-To: sigtran-bounces@ietf.org --===============1385258451== Content-Type: multipart/alternative; boundary="0-1950985010-1174983766=:70174" Content-Transfer-Encoding: 8bit --0-1950985010-1174983766=:70174 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, can you please clarify few questions regarding Notify procedure: 1. to which ASPs the Notify message must be sent: a) inactive or active ASPs for which AS is known either by static configuration or by Routing Key registration procedure b) ASPs in a "pool of inactive ASPs" I am interested if only ASPs in a) should receive Notify procedure, or if those in b) should receive it too? 2. How to explain the following statement , RFC 4666, section 4.3.4.5.: "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify message should be sent...." How can ASP go up to INACTIVE state within particular AS ? 3. the section 4.3.4.5. states that Notify MUST be sent to all ASPs in the AS (except those in DOWN state), but in section 4.3.4.3 ASP Active Procedure, paragraph describing Override mode AS: "The SGP or IPSP MUST send a Notify message (Alternate ASP_Active) to the previously active ASP in the AS.." shouldn't Notify be sent to all ASPs (including those who were previously INACTIVE)? Thanks in advance! Kind regards, Dario --------------------------------- Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. --0-1950985010-1174983766=:70174 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
can you please clarify few questions regarding Notify procedure:
 
1. to which ASPs the Notify message must be sent:
 
a) inactive or active ASPs for which AS is known either by static configuration or by Routing Key registration procedure
b) ASPs in a "pool of inactive ASPs"
 
I am interested if only ASPs in a) should receive Notify procedure, or if those in b) should receive it too?
 
2. How to explain the following statement , RFC 4666, section 4.3.4.5.:
 
"When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify message should be sent...."
 
How can ASP go up to INACTIVE state within particular AS ?
 
3. the section 4.3.4.5. states that Notify MUST be sent to all ASPs in the AS (except those in DOWN state), but in section 4.3.4.3 ASP Active Procedure, paragraph describing Override mode AS:
 
"The SGP or IPSP MUST send a Notify message (Alternate ASP_Active) to the previously active ASP in the AS.."
 
shouldn't Notify be sent to all ASPs (including those who were previously INACTIVE)?
 
Thanks in advance!
 
Kind regards, Dario
 
 
 
 

Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos. --0-1950985010-1174983766=:70174-- --===============1385258451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1385258451==-- From sigtran-bounces@ietf.org Tue Mar 27 07:29:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW9qE-0004YA-IB; Tue, 27 Mar 2007 07:27:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW9qC-0004Xw-MG for sigtran@ietf.org; Tue, 27 Mar 2007 07:27:52 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW9qB-0005ZD-8W for sigtran@ietf.org; Tue, 27 Mar 2007 07:27:52 -0400 Received: from ns.pigworks.openss7.net (IDENT:q1reRkNRHWuzNX/avy4ZnPO9osBhgKIH@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2RBRms07107; Tue, 27 Mar 2007 05:27:48 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2RBRlo28000; Tue, 27 Mar 2007 05:27:47 -0600 Date: Tue, 27 Mar 2007 05:27:47 -0600 From: "Brian F. G. Bidulock" To: Dario Filjar Subject: Re: [Sigtran] Notify procedure Message-ID: <20070327052747.A27879@openss7.org> Mail-Followup-To: Dario Filjar , sigtran@ietf.org References: <588065.70174.qm@web30006.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <588065.70174.qm@web30006.mail.mud.yahoo.com>; from dario_filjar@yahoo.com on Tue, Mar 27, 2007 at 01:22:46AM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Dario, Please see comments below... Dario Filjar wrote: (Tue, 27 Mar 2007 01:22:46) > > Hi, > > can you please clarify few questions regarding Notify procedure: > > 1. to which ASPs the Notify message must be sent: > > a) inactive or active ASPs for which AS is known either by static > configuration or by Routing Key registration procedure > > b) ASPs in a "pool of inactive ASPs" > > I am interested if only ASPs in a) should receive Notify procedure, or > if those in b) should receive it too? Just a). But in the case of NTFY("Alternate ASP Active in AS") for an Override AS, the rules are, of course, different. > 2. How to explain the following statement , RFC 4666, section > 4.3.4.5.: > > "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular > AS, a Notify message should be sent...." > > How can ASP go up to INACTIVE state within particular AS ? Look at the state diagram. An ASP moves from ASP-DOWN to ASP-INACTIVE for an AS by completing the ASP Up procedure where the ASP is associated with an AS by static configuration, or by completing the Dynamic Registration procedure for the AS. Whenever an ASP becomes newly inactive in this way, it should be sent Notify messages indicating the current status of the AS because the ASP might not have knowledge about the current state of the AS as viewed by the SG because it has not received previous Notify messages. > 3. the section 4.3.4.5. states that Notify MUST be sent to all ASPs in > the AS (except those in DOWN state), but in section 4.3.4.3 ASP Active > Procedure, paragraph describing Override mode AS: > > "The SGP or IPSP MUST send a Notify message (Alternate ASP_Active) to > the previously active ASP in the AS.." As I said above, the rules for this particular message is different. > shouldn't Notify be sent to all ASPs (including those who were > previously INACTIVE)? This particular message must not be sent to the Overriding ASP, but can be sent to all other ASPs in the AS (except those in the DOWN state). --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From hadlow@18k-body-jewelry.com Thu Mar 29 03:46:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWpKz-0005PE-4O for sigtran-archive@lists.ietf.org; Thu, 29 Mar 2007 03:46:25 -0400 Received: from lstl-pisapia.lst.ens-lyon.fr ([140.77.101.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWpKt-0005QH-6D for sigtran-archive@lists.ietf.org; Thu, 29 Mar 2007 03:46:25 -0400 Received: from lstl-pisapia by 18k-body-jewelry.com with ASMTP id 5B07F99D for ; Thu, 29 Mar 2007 09:51:25 +0200 Received: from lstl-pisapia ([153.161.197.193]) by 18k-body-jewelry.com with ESMTP id 384C56495462 for ; Thu, 29 Mar 2007 09:51:25 +0200 Message-ID: <001101c771d7$065883c0$02654d8c@lstlpisapia> From: "is radical" To: sigtran-archive@lists.ietf.org Subject: includes Date: Thu, 29 Mar 2007 09:51:14 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C771E7.C9E153C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.5 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 ------=_NextPart_000_000D_01C771E7.C9E153C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C771E7.C9E153C0" ------=_NextPart_001_000E_01C771E7.C9E153C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hampered by the lack, of effective libraries, enable. On this site, last = update is radical. Library provide instant platform what, you get. Fancy = generators in respect competes. Contains full featured debugger also be = used. Greatly reduced source code size rapid suite it. Creating rich, = text resources like! Be used develop nonu combine rd party tools = compiler. Work gcc mingw or compilers including free, express edition. Full = featured debugger also be, used, develop nonu combine. That provides = completion navigation can, work gcc mingw. Provides completion = navigation can work gcc mingw or, compilers. Express edition contains = full, featured debugger also be used? Whose number one priority, programmer. Compilers including free express edition, contains full featured = debugger? This, site last, update is radical and innovative. Languages, while preserving cc runtime theide. One priority programmer = great language but are. Sometimes, hampered by the lack. This site last update is radical and? Win bundled mb linux deb rpm, amd. Both whichever need, new release recent license! Contains full featured = debugger also. Size rapid suite, it includes set sql etc. This site last = update, is radical and. ------=_NextPart_001_000E_01C771E7.C9E153C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hampered by the lack, of effective = libraries,=20 enable. On this site, last update is radical. Library provide instant = platform=20 what, you get. Fancy generators in respect competes. Contains full = featured=20 debugger also be used. Greatly reduced source code size rapid suite it. = Creating=20 rich, text resources like! Be used develop nonu combine rd party tools = compiler.
Work gcc mingw or compilers including = free, express=20 edition. Full featured debugger also be, used, develop nonu combine. = That=20 provides completion navigation can, work gcc mingw. Provides completion=20 navigation can work gcc mingw or, compilers. Express edition contains = full,=20 featured debugger also be used?
Whose number one priority, = programmer.
Compilers including free express = edition, contains=20 full featured debugger? This, site last, update is radical and = innovative.
Languages, while preserving cc runtime = theide. One=20 priority programmer great language but are.
Sometimes, hampered by the = lack.
This site last update is radical and? = Win bundled=20 mb linux deb rpm, amd.
Both whichever need, new release recent = license!=20 Contains full featured debugger also. Size rapid suite, it includes set = sql etc.=20 This site last update, is radical and.
------=_NextPart_001_000E_01C771E7.C9E153C0-- ------=_NextPart_000_000D_01C771E7.C9E153C0 Content-Type: image/gif; name="features.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c771d7$065883c0$02654d8c@lstlpisapia> R0lGODlhsAFMAYcAAA4BCnwLBAB6AIGDAAAAg4AAgQCBi7bBv7bQtq7L8jEaAFwfBYohAK0ZAMwa DN8iDABMAClAAENJAF1KAIdFCKZECco2ANJBAABkABxsAE5pAGFdDotsAJNsALRoC9ZTBgCIABZy ADqCC1+KAHJ2BKyNALaNCNGAAACXAhGdAEmnAG2mA3ykAKqYB7qqBt+UCQW8CBbKBjy2CVfNAHXK A5HDBcyxAOi6AADlABrlAEXrCWnpBYTpAKjaAMzeANPuAgEAOh4NQUwAPmYASnMJPZsJS70ARt4E SAEpNx0lSjIbTmUUQYETTa0VPbMjQdoUOAA+OiI6N0U8SlVBTXI1Sa5JNsxBP9FGRAJlPC1uOD1e R1NjToZXD5NVTsZjTOhSMgCETRl2PEt+Rl+KOYd2RaR8MbOCMu14RgCXPRSTQjasMm6rNY2kOqOY MrGSQuaSPAC5Shq6PTK/Smy+NoW7QKixRs6zTum0RwDqPSjjOj3uTV/mR3/SR6vbO8PlOenTQwAA jSQAeEYIfl8CdnwAfaUAccsMeeUAhgAShiEshEQajlcSjnoqiasjibMrhuEffwdNdB8+hj41emVB hoo/iaI8hLFHf+s6hgBqgSVujUlWhFRmhYJriKZndLFZi+xqigGIdhmFdj50e2uAf4qOfKCKjL18 c96KdgmfjR6VgEyfgGaafISrhJqZesOXfeysjADCgiy8dT7FhVO2fHXHiaS+eMbAi+bFjADqgCrU jUvnglHueobThqfufMTdidLXewYLuCYLyEEHslkJwIkAwZUAyM4AuOoAtAAUty0dyz4bxmcXwY0l wJMUxbYdydMttAI2vR1NwDJMtlZJvYVAxpw0yb82u940vQBbuShlu0peyVdkzoljxqNlxr1cxtts ygSEvhx1wDWDsWaKzH92yaiDwsNzxNN1sQCuyx6twkeTtmKRv36rxausvsGYxOCVwwXFxCG0u0q3 smG5u3m+xJbHwf/346yRq3h9dPgAAA31Cf//CwsA//8A8wD///P/9CH5BADZ4XAALAAAAACwAUwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKFPivpMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKNTmyqtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdupcOOedEu3rt2PcvPq3cvX5t2/EfsKHkyYKeDDGgsr7om4sePHAxdLnky5 suXLmDNr3sy5s+fPoEOL9gm59OjTqFOr7lu6tevXsGPLnk27tu3buHPr3o179WbewH0LH068eGHg yJMrX878rHHLAKLvlK6zufXEOqMDQKmdu3bq/wiI/38O83tK8egJeO/+jz3L6/BFTgdf0n377+Dx b09p//7+8vrRxxd+6+lXX4ACkqegXhhpR5CDA31nD4QTBlgQhQJhuBCCAHCk4UX4PUghhA7qF9+J W/Hknn39mcSeeSetmCCA/x24n4zbBRijgfy1yBKL9L3I4YJEioajizPauGON/ilZU39C/schjjAi WeVLQFJXJYKYoXgdidGJ2CFCGEoYYZgfOqQhmGNWOOWZaIaZoYlqyjmnhWTaGVaRfGbEJpwKramn m2k2JOiYI5YYZ5t/3jnRoSEeVKiXlHrUU3dH/igglATaxOmN+WkpXaZUJrlSlqDO6KNLpvLpKk4a 0f/paEKHGmTmo4M26qajiSKa660MlannhxwGO2ilyI4UwLLMEtTsQM/aE6200w7UwLUPKaDtQNoq UNCz0YK7LLUBcLttt94a1O1D017bAEHuqovuvAuNm+y9VclqD7oC8dvvtv8CXNC67NpL7oV4Hnxw tPMKvG/DDeUj8cT5BJyuvwRBTDC+HHsFrMUY2+PAyCSTjFC1C1Fsj8oIR2rPAzALBPMDL8csELPV QmyorAgaNPHKFEts1qtEx4SzSvOqhDOzK3VbU8klC+V0UjyiNHNJM8Nc9NZI3YWyQ1nT/NHGanFt 9tl7rYr22qd13BADcLst99y5QWA3RWznrffeZtP/PTTfgAdOnN+EFw6b4KsZrvjijDf+96VM5tSq AAIQZvflNWGAQVI4dN65THafhAIKMI1uOukuUY64YhzdrREccCgEAwxrzT6Q7RBBAcVVuOO+0D+h IynT7DG1unpoYIDh0+SV95U8Ss/LBAQQVEsZuUqqmzS9TNG/lP3xgm00/fQFAWM+MBB9bM/45M/p /kDswx9/QegZVD9D7ROU//nm058eSug5CfuoZ5L/vWQ8JUFgAgN4EgWGRz0x2d5J+AeMBkIQfKzx U4f01L/+OYR8+ROIeERIgIHwgx8COeGZKjSQ+o1QfusDAkE6iL6FhFAg+UtPCQfiQQ8KhIbyG98K /48lKUYZ8X04lOEKHfLCIMYQho6DzQibyMKIxElES7zTEatojxc28YZJDKMNlag/MgJRjE8koRpT iEIV/rCGdUJiGkM4rDYxhIr26CEciRjFxuhrV3UClhvtMUhCLdFOckKkHeHEx4IUko1QnCEcfeiy NLbMIRQsSPvoaMdG2mqRidxiH0ujyE8ycYddRGUpeXi+Q25xlZeMIxYj2UJUNvFDj5zlhja4SD0S hIq5pBUofZXFUTqGinhM5c50CUs5btKMNaQkMdeYzIM0EY/HgqUXVblIXSrEl670pvF25J0DYdA3 5ptgBRfowJYEqUZVWyBKBkhAUS2JSVdiVT7vo/+SeBqwJOmc5/iKZ717ltMkAXUJPRG6zoSO85xP MaZEJ5oiiFr0ooShqEY3GhKMevSjcuGoSEeKEZCa9KQo5QxJV8pSe6T0pTBlTEtnStOa2lQj5frW QtLVmqDd9KcO0UkAUjLUpZhqAUkpakyB+hVQboVmNutKTrES06raBKkmwao7gaJVrcpkqMuqT4y+ ihIF/ENbVk1rdUAUoVgORGzFFAi2DPWgC33LYCMT2c2cla2CzPVdzpoqU1m6EweYxLCHTaxJIDDW 9pyEASWBLJa4cxLERvayJTHrWRVrWZhoVrH/6OyN1EralmQEAvZALUFUm9q6CoS1BKHAQGTLENr/ zna1bc3QQGArENra9m0FYcBAhPvawRp3IiiwR3IJIoCBNHcgGBjIcu3qSdxaVyDTZS1rp+vNhvBW u7s9Lk17wljKitUkqAOeSj4nk/SWxL3/2VxJ5KvelBBvJuU1CQz06yKQihcrODAIeKU7kAALxMD2 eG6C6ZpbAmPXwfaIrqQeQrkKO/fCxc2wPWj33w4vxHMKMV1BQBzIbnK3RArhLUdE3ODglDYuKOqm h2eckKLh4MWmpXHhVKzjHvv4x0AOspAfh+OIDtk0RV7bkX+XZKEsebD3o8ikFNdkydglyhPBcvp+ NcxbnRCFCRFiGcm4pyprxkPq06CMH9LKibSZ/5VwTKUOgyhmTd6wzk++Tk90yMCfqI1GN8mSBcfT Zz6384EX7LOZk/xnFT1UU9cjqPXgmaQoRS5Ki26y2gTdJB1ZaZ/+SRCnsRSqSUN6SetpUqYZbSpO T6nUnfr0p1ANaFU7qZ/v3FSsz5ZnXP1RV6824qI6OWwxVQTYnqyVmKbs4lXXJFYJA2SveEltQM0K kNjOtkQUJexAcfmT1VWIs096pXhiOlO2RretPbXrP8+6R5Ee995AIixg/alX1sZ2vS2ir31f25Bu 7XV85oNPXRtcSaSiUqhpfWtSl9vSVvo0ruMtb5gerSQXN0nGnYQp8Ljr4w1AyQJGTnKvnhWtGv8P q0zQlZKSl/wkS9u4SaZmFIEDhicxZ1pZUU7rjk8a1GFLCc1vkrWJzyhsWkMazyv+4pivhGRMt4yQ l7L0vNkcRUpxV9S3rtKrkPzqYNeKUuDG9bJnJuxoj43ZXdXrtWMQqG6Pu9znTveiLEdzEk77fxfU 6LqPWzmzCzyHQ1IsvVM0eYgHA4Up1xV64tkjjgfjXfwuFYw4/oOSr8rlETLAh2hZy4a/104Gyj7C +HwlhobJP0vy5dZT/sWYvokO4d2fgb7ky//AfUrOB9CEsmT1Ntr16/lm+WeSMWEYav2XCaL85efb 29G+1ZT5V0RfhRs7w/dMg4qtRXwDCkP3Az3/RCj4Zn9zPvN1fnzooxhtQ+e7UNy+/i4jhWXxd7+6 zF5O9ocSz06XmqHrRHt9FxO8x3uINmiQJnypBlNhB39EFGUOmH9bVm3ZNineV33WsX9KsSo+onAK Z04R53ChFnsNt4DpJioUl1HrZxUEdyqqkmsPZ24PNSUSt3AuaGrBB2rhs4J3EYEYuGzdVEm+JoS6 Un3URmxpxoOM44PgBhZp0jPPF21KOIXHxke/xmXyR4UDpyADeBla+IV4oYGvAoZkSBZieIZo6Btl uIZekoZuKBVK9YY8sRyCxW+7wRKdNRwmN28X4QAD4YfwMlc1oy4Z0xCAmBGHeBE81RVrNhAL/3AV gCV2UxGHVZVf+eVYmBhaoZWHkiVZRtUTeVgcl3OJecEenvgPkJWKmIVxKqeJI2MScOOJmMM2GEFc 9mCLvzVcuhherdUQHEAQsegQ0WKLl7NbrjNccaNFGtaLChGMvUUBuXiMqXWM9ZWJ8bVYwEOKZBcT s0gBJuGNLTGLqXiK2ehn52WJkTWOqLiKkhU8+eWJKVg0GZFc05V3BcFd3NVcCrYQCmaPDLFc2RVe qjVgyvVgzKhaCraPCaGPBlmQBrlcjAJhBKlgrsNaEuaPCAGQApGQApF3HtmRrzWQ0AWSG8l4/8hi ETaSD7mSDvlcCjZdMHldorcT+7VfJWGT9v91EjhZjjFBX9XoEjdWEkH5DzjpXuWFjiVRXs3zD0s5 Wi+xk83TlClxlKJzEox1iUOJlPTlkyuBlEvZPFppEvIlJSWhDylhlmU5Wee1ldiYX1FZEs2DdzrJ X/NlXrSIEdGVd4NnVy3mkA3hjxh5EAiGYG2yjyjpl8s1mLezYQ6hDwSBd661WtLolwWZjwV2mRPS lwcRk5mpWw/GmS2JYSqGKA0xeBwWkVlEmp3JkQu2kRDGixqFWqzlmANBmylJkq/5jwbBXQhhm7aJ YJbpmvagmPbgm5LpEPjoYJxpnA0pELYpnK3ZmqCZEMSpXCjJkBqmWsRpmiWpkLTSYCCGYPb/yGHk aYwEaZHOZZIzuRNoaRL68J7taYNWORNL6TmShontSYqzmJShc5T7+ZMuEZ//IJchyJ+XyCQC2p5f WYMugTmkiBKkWGFMWY35FXj9dV4tsaAtwZWk1UcIdhFOEY8zIaKlMzo0koIkmlJR5J110Yh1waIG kYlyKBzKAxUUoX6AAaN7N6NdwkRs+KMHwaNCihJAWqRGKlIuSilJehVxdqQVwRQp+ipRShQXFBRV GhSPNh0oYYB9kxVLqm0QmIVJdHxWMSKRiRBh+qUdQWYdoaZuhmaBwpduSjckwkUAF6ee2ZltUkI7 xEu/dEv2ky+5hZob0mBz+oO2ZG1+Ghmn/1agFyoUU8oq/HQe4dFYkTocDeKZiZSnS6qanfmpxKap hmpsheqp+sZFpmqq38mpbOWpqrqphcqqwtZt7xduLmN+ePqpojqoxoSavqqZTTiqeQqqu9piX3pF rvo+1kddaiKsxxaZhEqssSqtunVeZClWTikT8PSoOVIejRV8DOdR1zquj/ojF3qtMjquqlKu5oqJ 2fquGEppxcOt2fGt/0Gtneqs0pqqfNmszuqmnaSvGyRRv1qsx1pHA6urBaunw8JgqrmwtAqsZEKq dqiveiqx0Gqsg5ortvIQAcuq/gqyIHuod5gdo2KNDAoU6Opu3uqu8fqyWxUVBYeC9CqC5f9KrjBr l5JaszK6syhrrzzbJ8pxrAaLSBirq8khfQ37fNP6bwArgRyjVpd6ToM1pFZ7tVibtVq7dWgXiU5q hkYRiq7yWUJhWXu4VgJRMRSxiF9riIloEG/7GGyrFo9YEXPLZDTxHyHHE1Xnhg/wD0lXVptlEloX E2IrFzqHNYHbElplWK94EtdyEiRnElfDoKIFHn+7uH/rWZQLuJvrEoW7tzpBtoZbZBjBU2x7McAo ELY4gQ5hMgvhh4D4tmbaL9zyh3rFELYIqxcrELLru4rlibIIWojljulIjk83c5pFuk0DiyryNHUH jiUhvdkYPJiFvKeCjTLRiS8RVt57rtr/u46r+KAskV/SC45I+Q/US5VJGb7nO73hm1+UyBLD274v Yb7qu77WG46jyHDs8Z9ud4n5xZbo9V4xsZQAWr7hyxJvOaEUahIa6sADCjoFbMAPDJeiY6IQvMEW vG7pS74qkV4iDBMDLF8mLJbcCKH2i8D2+2J4+ZiwyYyQ6RAKuZcJ8ZELoZEOyZzMSKg8hhCshZrc 2ZxDTKgBmWFDPJwOgcO3+WHCepEey1wYFp3O+WSsqcQEoZgfuhDPiZvUiZkhxpJJjIQEYcMKoWC0 +Q/5uZ/u9Q+mo5MWKpRWab0j3MEuQV/o2hLtucdw+T0wgcA4uZM7OZRyV2EszMAYDBP0/yWhJNyf LmGTkKxfxGOTU5sTIFwUhHwUSFnHTzmXN4kS6XXIbsjHL9HGU3HJQ4HKnRHIEOzHQJlq28HILby1 ksGhqby/tJy1qpzLvNzLvvzLwBzMP/GFwlzMxmxR/GBSdQFmbRsSqNRHkkFAPQsVkXOleTu1lSwV AZiC0vwPWkGyYAfOIxGEzwoRYiZjTYoW4pwRbbaoymhMO9Fn2yqfHDep7JRoBfRAB1UUl4YTUeqU 2Syz7Mof/ZVr/jpNyXpchJrQ+6qsIvtKvBqrroqwhiqB00a01PWxmUnRtUq0qYqweWzP1gjQA03Q 1gq+GOpRbIW0S9u7Ls3QCy2yq/qwo/8KscGisQyGMA9N08Uq03nCQgkd0xGNrz29qi/t00BFLBod 1EMt1EddqglL1K4VrRM7rGoqY05dsBrt0njK01kNrEINtTZNrdAsOTW7sjCLsz/7syHdT/yE1int snHt1ilNotcD12wtao4aswAdJDx712fdX8YysAsNtXTTgnUNrhHXrfG6In89gN2K1/iUs+2arvOK 0mut1pO91u1K0ieds5LNrVnKowEdaC07s9/a2DO4Kdrq2KAt2jhYgtkr1+umg114E0q4zuV8ZMd8 2Uhx203WzMI93DXW28Z93Midy8TtJXXLFnfLFc89G0qTt6NR2nxyuHoxv0eB3ZkBdTj/8bkt8Vmi CxrcvTe7DBfYW7bOmxKdFYuTka01kd4oYVnWrRRT47hiW98ZZBHFOFvQaJ4WqTmSqV2TmRAccODI SIwFfhCy9d+su4shWREEGVu3hTc3a6Ao4d7TC400wb0pR4nQKL06eBIhXpea81jb6BIc8A8HTuIc fr2rOBNFVVTGa6Dn/RwE7MY6fsGcvDljiV8tTDqok+MsocFDjsL265auvBIEWjl+7JO2TBMEnL7Z 6uM0wb4XPMFaTuQK3MeJzMksceJaXseePaBi3hJ1rKFcDhoXcZ4EwZmmyltbnBA8DFuqWtWriWFD XJ25+p5VvIyUSRGoVV9YzsqfXBP//4mW7anZJIzkWt7ADaq9QZmV5Zi+aomJac7BW8PJ7mXoAPyg opwSOX6JcVzKFazmSI46prwSOBnBh0yi39kmh+nmEkE7e3mYOEzVGbmYAsFh/a2bBkliBzacAfah vHnDKsmcTHwi1bnU0EmRm8kQScxdSWzUCT1gFtaYsLld0jU6GaGerFmdc+6w2w6yE54QtH7uBzFg BEmPgR6YBwGZ0TVg08nsnUMQXWzI3Z6cTLuQjPdcvGXRDabv71zvvWmxHuGP+zYmvPnD/domM9yd rSl4Oc3EgdcQoHnxQ32mIGLYN3c8/1HqPmvoRLHq5yTLyX0TO1kYK8/myw0ZHi8WbP/6Fyl/tS+/ tS8PhjXPOjkPokDRzTYB9Gm1OGI68/MnIbqtFpN00xXbr732zCKRqBSL50hr1J4nZb9kTX/xzG1S QzHrzzh2FUkfxVadp5J351bfEDjK9MPaGroObna09v5DRcMEz/OBgLKtEvIs0l//H9bsWKw9zXq/ evKcH6Zd0DVSpX1XpRCkaCcYj42fQN6ssEc7spXfRS3UYjsE9T/F02Rt7Q5NV2//+VHN9rtKzo9C TpmtrZjN6PFY5vMs+HZZ5n3/15mGs7Ff+5y9VW2d2MLD+raf2iMKtL5/2p+9+t56shc+1ybtro8W 2sz/dk2/rByP5wxdqhK71VWfq2T/rf1k/9BOH6cRK9U3jSZnOvoZ+/kTBv5tzzj1evy93/zwmvzL b9kl/fW7n8cpGvttbddwDRAA/g0USHDgQYQJ/wlkiLCgQYgKHQKgOPGhxIMUK2a0eBHjR5AhRY4k WdKkSXspVa5k2VKlRgAvKa6M6bKlxpc5bd5kCZOmTqA7e/acGROnUKQ2a9pb2nRm0pRLoz6dajQq 1KtMhwKVitWrvZMLw44lW9bs2YRfkXZV29btzaNv5c6lu7buXbxQT170iNbvX8CBS/YVXNjwYcQS CSdmDFhjY8iRx9KNm9fyZcyZ5bLV3NnzZ9ChRY8mXdo0acmpVa9m3dr1a9ixZc+m/10b5GncuXXv 5t3b92/gwYUPJ17cOHHbyZWjPd7c+XPo0aVPp17d+nXs2bEu597d+3fw4cWPJ69Q+3m55dWvZ9/e fWz08eXvfF/f/n384efv5w86/38AAxRwQAILNDCy/hJUcEEGG3TwQQjRO3BCCiu08EIMM9SwvQg7 VHBDEEMUcUQSZ/PwRBRTLK5EFlt0MSQVY5RxRv9etPFGHHPUcUcelaPxRyCDFHLIlXokkUgkWzJy SSabdPJJKF1LcsrLoiSPSizBsnJLLrv0sqwswxTzxC8FG/PM3MpUc00p0cSMTTjjdNJNOuu08048 89QTRTn79BOwPXv7c1BCCzX0UP+yAlWUPkQbbXRRSCOVdFJKK7WUN0dZu3RTTjv19NO8MhV1VFJT A7XDUuc81a1Ul1v1VVhjxa7VLWW1iVZcu7R110hz9fVXYGHk9bxghzX2WN2CRRBZZt1U9lloC232 w2irdXHaUK3Vdltuu/X2WmzDpfJRcfX8VsBy08XzXDnVdffdZNmVd14D4bU3RXrzBfBeflHV91/7 +rUM4NoEfvBbgwnOz+DqFHb44foYlnjihiG2+GJDKZ4OY4479vhjkNnUOLOQSzb5ZJQbG5nGlFt2 ecOVY47uZZoNu7dmnM+SeWeeS8v5Z6CDrnVloUXqua6i2Tt6aabfKrVpqKP2NCAAOw== ------=_NextPart_000_000D_01C771E7.C9E153C0-- From sigtran-bounces@ietf.org Thu Mar 29 04:19:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWpqT-0001yF-HQ; Thu, 29 Mar 2007 04:18:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWpqS-0001vT-8O for sigtran@ietf.org; Thu, 29 Mar 2007 04:18:56 -0400 Received: from web30013.mail.mud.yahoo.com ([209.191.69.30]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWpqO-0004hk-SA for sigtran@ietf.org; Thu, 29 Mar 2007 04:18:56 -0400 Received: (qmail 68960 invoked by uid 60001); 29 Mar 2007 08:18:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=vIewvD1vGSfyD9P1pYvGuwV3CPVisYNqJN9AzLr4/UZLywOK0Cwzy9qAVrvpfSOc2fAx8fq6BNukz5O1hZ861orZQXYbZx2UdqvoW75SNh8pdsL6seHQpCPZtEJ9olauI/FWjDMoscpRhVSQvCl4rtCTJFz2MjkBH3JA/I+rxeY=; X-YMail-OSG: WnbJGmQVM1lTu2LAB_lM2Y_1KSz7B7O3xsDEThgkUQ0j5PWu7BWYXwXGl.ZXZFLfvQ-- Received: from [195.29.145.167] by web30013.mail.mud.yahoo.com via HTTP; Thu, 29 Mar 2007 01:18:52 PDT Date: Thu, 29 Mar 2007 01:18:52 -0700 (PDT) From: Dario Filjar To: sigtran@ietf.org MIME-Version: 1.0 Message-ID: <101728.67110.qm@web30013.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sigtran] correct Error code X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1330236196==" Errors-To: sigtran-bounces@ietf.org --===============1330236196== Content-Type: multipart/alternative; boundary="0-1129366904-1175156332=:67110" Content-Transfer-Encoding: 8bit --0-1129366904-1175156332=:67110 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, what would be the correct error code for the following situation: ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message. How SGP should respond? thanks in advance! Best regards, Dario --------------------------------- Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. --0-1129366904-1175156332=:67110 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
what would be the correct error code for the following situation:
ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this
RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message.
How SGP should respond?
thanks in advance!
 
Best regards, Dario

Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A. --0-1129366904-1175156332=:67110-- --===============1330236196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1330236196==-- From sigtran-bounces@ietf.org Thu Mar 29 05:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWqb6-0006tp-OF; Thu, 29 Mar 2007 05:07:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWqb4-0006tY-UV for sigtran@ietf.org; Thu, 29 Mar 2007 05:07:06 -0400 Received: from web50803.mail.re2.yahoo.com ([206.190.38.112]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWqb3-0000WF-Jp for sigtran@ietf.org; Thu, 29 Mar 2007 05:07:06 -0400 Received: (qmail 21521 invoked by uid 60001); 29 Mar 2007 09:07:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kxmCAarFb+TocceKUkRUrY36zSYIH6R5Ul9G9lpk2YEm9F4qiAjGYLkrYjXewshyk25QjyTKlGHY8kH9aY/c3Z0pLItEYZYhSGebAhbD4qQlSzgCWobafArAeIQwWoVdwGpZpmik4vniPtVynQ9WIA4/lWd563/NXhptCwxLY+A=; X-YMail-OSG: 9KV57AwVM1mQ80mH9oWWNfyp9XIbaBZ_JGYivVIinHxHz1XmZyLAU1gUbW5QGH0rBlkj1RSNCO298lfxWsBIMx8Mb0QKnXRfIbHVxMV.mOOyFBhD9CI- Received: from [128.251.168.91] by web50803.mail.re2.yahoo.com via HTTP; Thu, 29 Mar 2007 02:07:05 PDT Date: Thu, 29 Mar 2007 02:07:05 -0700 (PDT) From: Aditya Subject: Re: [Sigtran] correct Error code To: Dario Filjar , sigtran@ietf.org In-Reply-To: <101728.67110.qm@web30013.mail.mud.yahoo.com> MIME-Version: 1.0 Message-ID: <369081.18973.qm@web50803.mail.re2.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298075619==" Errors-To: sigtran-bounces@ietf.org --===============1298075619== Content-Type: multipart/alternative; boundary="0-907648283-1175159225=:18973" Content-Transfer-Encoding: 8bit --0-907648283-1175159225=:18973 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Dario, The SGP should respond with Error "Invalid Routing Context" to the ASP as the RC in question is not defined/configured for the ASP in question. Aditya Dario Filjar wrote: Hi, what would be the correct error code for the following situation: ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message. How SGP should respond? thanks in advance! Best regards, Dario --------------------------------- Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A._______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ---------------------------------------------------------------------------X---------------------------------------------------- Don't take life too seriously... Nobody comes out alive anyway --------------------------------- Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. --0-907648283-1175159225=:18973 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Dario,
The SGP should respond with Error "Invalid Routing Context" to the ASP as the RC in question is not defined/configured for the ASP in question.

Aditya

Dario Filjar <dario_filjar@yahoo.com> wrote:
Hi,
what would be the correct error code for the following situation:
ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this
RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message.
How SGP should respond?
thanks in advance!
 
Best regards, Dario
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A._______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran



---------------------------------------------------------------------------X----------------------------------------------------
 
Don't take life too seriously...
Nobody comes out alive anyway

Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. --0-907648283-1175159225=:18973-- --===============1298075619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1298075619==-- From sigtran-bounces@ietf.org Thu Mar 29 06:06:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrVn-00005I-IR; Thu, 29 Mar 2007 06:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrVm-0008Vw-1s for sigtran@ietf.org; Thu, 29 Mar 2007 06:05:42 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWrRH-0004Lw-JO for sigtran@ietf.org; Thu, 29 Mar 2007 06:01:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 066E820B86 for ; Thu, 29 Mar 2007 12:00:59 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-fd-460b8e5a1b52 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E636C209D3 for ; Thu, 29 Mar 2007 12:00:58 +0200 (CEST) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 12:00:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Mar 2007 12:00:58 +0200 Message-ID: <425A3BC99494A4409BEF99524478ED5201F342E3@esealmw103.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: Acdx6SXou1WnplB/S4mB9Hs8CXa5rg== From: "Jan Scheurich \(AC/EDD\)" To: X-OriginalArrivalTime: 29 Mar 2007 10:00:58.0614 (UTC) FILETIME=[263C1960:01C771E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.7 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [Sigtran] (no subject) X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1175817287==" Errors-To: sigtran-bounces@ietf.org This is a multi-part message in MIME format. --===============1175817287== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C771E9.25FA8BA6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C771E9.25FA8BA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Rfc 2960 explicitly foresees the possibility to respond to an INIT packet with an INIT ACK from a source IP address that differs from the destination address of the INIT packet. Motivation being to support establishment of MH associations in hosts where the SCTP user cannot fully control the source IP address. Apparently this has been the subject of some debates a couple of years ago and I wonder what the status is in todays SCTP implementations. Do clients support that kind of server behaviour? I would like to go one step further and ask if the following scenario is legal from SCTP perspective and would be supported by common client implementations: +--------+ +---|Server 1| +------+ +------+ | +--------+ |Client|---------|Router|---| ... +------+ +------+ | +--------+ +---|Server N| +--------+ The SCTP server is a cluster with N (single-homed) servers having individual public IP addresses. The SCTP client is provisioned with a virtual cluster IP address and server port number only. The cluster router performs load sharing of incoming SCTP INIT packets destined to the virtual cluster IP address among the servers.=20 The selected server would reply with INIT ACK without including any explicit IP addresses. The source IP address would be the server's individual IP address rather than the cluster IP address. The client would establish the SCTP association between its own SCTP EP and the remote EP on the selected server, disregarding the originally provisioned cluster IP address. If this scenario is not legal, what would be the alternative? Would the cluster router have to do SCTP NAT based on remote IP address/port number? Would that work in redundant configurations (i.e. with replicated routers)? Any feedback is welcome. Regards, Jan ------_=_NextPart_001_01C771E9.25FA8BA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Rfc 2960 explicitly foresees the = possibility to respond to an INIT packet with an INIT ACK from a source = IP address that differs from the destination address of the INIT packet. = Motivation being to support establishment of MH associations in hosts = where the SCTP user cannot fully control the source IP = address.

Apparently this has been the subject of = some debates a couple of years ago and I wonder what the status is in = todays SCTP implementations. Do clients support that kind of server = behaviour?

I would like to go one step further and = ask if the following scenario is legal from SCTP perspective and would = be supported by common client implementations:

           &n= bsp;           &nb= sp;        +--------+
           &n= bsp;           &nb= sp;    +---|Server 1|
+------+         = +------+   |   +--------+
|Client|---------|Router|---|      = ...
+------+         = +------+   |   +--------+
           &n= bsp;           &nb= sp;    +---|Server N|
           &n= bsp;           &nb= sp;        +--------+

The SCTP server is a cluster with N = (single-homed) servers having individual public IP addresses. The SCTP = client is provisioned with a virtual cluster IP address and server port = number only. The cluster router performs load sharing of incoming SCTP = INIT packets destined to the virtual cluster IP address among the = servers.

The selected server would reply with = INIT ACK without including any explicit IP addresses. The source IP = address would be the server's individual IP address rather than the = cluster IP address. The client would establish the SCTP association = between its own SCTP EP and the remote EP on the selected server, = disregarding the originally provisioned cluster IP address.

If this scenario is not legal, what = would be the alternative? Would the cluster router have to do SCTP NAT = based on remote IP address/port number? Would that work in redundant = configurations (i.e. with replicated routers)?

Any feedback is welcome.

Regards, Jan

------_=_NextPart_001_01C771E9.25FA8BA6-- --===============1175817287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============1175817287==-- From sigtran-bounces@ietf.org Thu Mar 29 06:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrpd-0004Ty-FZ; Thu, 29 Mar 2007 06:26:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrpb-0004To-RG; Thu, 29 Mar 2007 06:26:11 -0400 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWrpa-0000pB-7e; Thu, 29 Mar 2007 06:26:11 -0400 Received: from [192.168.1.2] (p508FF760.dip.t-dialin.net [80.143.247.96]) by mail-n.franken.de (Postfix) with ESMTP id 3E2D580000B9; Thu, 29 Mar 2007 12:25:50 +0200 (CEST) (KNF-authenticated sender: macmic) In-Reply-To: <425A3BC99494A4409BEF99524478ED5201F342E3@esealmw103.eemea.ericsson.se> References: <425A3BC99494A4409BEF99524478ED5201F342E3@esealmw103.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EAEBC55-CE08-4AC0-95BA-499AB71CDF0C@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Sigtran] (no subject) Date: Thu, 29 Mar 2007 12:25:50 +0200 To: Jan Scheurich (AC/EDD) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 4.3 (++++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Randall Stewart , SIGTRAN , TSWG X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi Jan, see my comments in-line. Best regards Michael On Mar 29, 2007, at 12:00 PM, Jan Scheurich (AC/EDD) wrote: > Hi, > > Rfc 2960 explicitly foresees the possibility to respond to an INIT > packet with an INIT ACK from a source IP address that differs from > the destination address of the INIT packet. Motivation being to > support establishment of MH associations in hosts where the SCTP > user cannot fully control the source IP address. > > Apparently this has been the subject of some debates a couple of > years ago and I wonder what the status is in todays SCTP > implementations. Do clients support that kind of server behaviour? > > I would like to go one step further and ask if the following > scenario is legal from SCTP perspective and would be supported by > common client implementations: > > +--------+ > +---|Server 1| > +------+ +------+ | +--------+ > |Client|---------|Router|---| ... > +------+ +------+ | +--------+ > +---|Server N| > +--------+ > > The SCTP server is a cluster with N (single-homed) servers having > individual public IP addresses. The SCTP client is provisioned with > a virtual cluster IP address and server port number only. The > cluster router performs load sharing of incoming SCTP INIT packets > destined to the virtual cluster IP address among the servers. So the client sends the INIT to A_R (router address). The INIT-ACK comes from A_j (where A_j is the address of Server j). Does the Server list A_R in the INIT-ACK? If not, the client should discard the INIT-ACK. If yes, the client should build the association and uses both addresses (A_R and A_j) to reach the Server. To get what you want you could use ADD-IP to remove A_R from the association after setting it up or use something I call INIT-FORWARDING, where the router forwards the INIT to Server_j, which responds from his address and puts a new parameter in the INIT- ACK which says, that the INIT was sent to address A_R, but this should not be used anymore. This is written up, but not yet submitted to the IETF as an Internet Draft. Basically it gives you support for anycast like services. BTW: The list to discuss SCTP questions is now tsvwg, that is why I'm CCing it. > The selected server would reply with INIT ACK without including any > explicit IP addresses. The source IP address would be the server's > individual IP address rather than the cluster IP address. The > client would establish the SCTP association between its own SCTP EP > and the remote EP on the selected server, disregarding the > originally provisioned cluster IP address. > > If this scenario is not legal, what would be the alternative? Would > the cluster router have to do SCTP NAT based on remote IP address/ > port number? Would that work in redundant configurations (i.e. with > replicated routers)? > > Any feedback is welcome. > > Regards, Jan > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 07:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWsvy-0005P8-MU; Thu, 29 Mar 2007 07:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWsvx-0005Or-OT for sigtran@ietf.org; Thu, 29 Mar 2007 07:36:49 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWsvv-0003IL-8a for sigtran@ietf.org; Thu, 29 Mar 2007 07:36:49 -0400 Received: from ns.pigworks.openss7.net (IDENT:yDfRAAm4tV48zq8H4ErNaAFPHWl3Hbi3@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2TBais14076; Thu, 29 Mar 2007 05:36:44 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2TBahE18639; Thu, 29 Mar 2007 05:36:43 -0600 Date: Thu, 29 Mar 2007 05:36:43 -0600 From: "Brian F. G. Bidulock" To: Aditya Subject: Re: [Sigtran] correct Error code Message-ID: <20070329053643.A18172@openss7.org> Mail-Followup-To: Aditya , Dario Filjar , sigtran@ietf.org References: <101728.67110.qm@web30013.mail.mud.yahoo.com> <369081.18973.qm@web50803.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <369081.18973.qm@web50803.mail.re2.yahoo.com>; from adityasehgal@yahoo.com on Thu, Mar 29, 2007 at 02:07:05AM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Aditya, Well.... RFC 4666 says: The "Invalid Routing Context" error is sent if a message is received from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid Routing Context(s) MUST be included in the Error message. In this case, the Routing Context value is configured. Also, RFC 4666 says: - If the RC parameter is included in the ASP Active message and the corresponding RK has been previously defined (by either static configuration or dynamic registration), the peer node MUST respond with an ASP Active Ack message. If for any local reason (e.g., management lockout) the SGP responds to an ASP Active message with an Error message with reason "Refused Management Blocking". So, in this case, the corresponding RK is configured by static configuration and the SGP has two choices: respond with ASP Active Ack, or response with ERR("Refused Management Blocking"). If the SGP does not wish to permit the ASP to activate for the AS, the proper error code is "Refused Management Blocking". --brian Aditya wrote: (Thu, 29 Mar 2007 02:07:05) > > Hi Dario, > The SGP should respond with Error "Invalid Routing Context" to the ASP > as the RC in question is not defined/configured for the ASP in > question. > Aditya > Dario Filjar wrote: > > Hi, > > what would be the correct error code for the following situation: > > ASP ACTIVE is received at SGP with RC that is statically configured at > SGP, but this > > RC (AS) is not defined for particular ASP which has sent the ASP > ACTIVE message. > > How SGP should respond? > > thanks in advance! > > > > Best regards, Dario > ______________________________________________________________ > > [1]Food fight? Enjoy some healthy debate > in the [2]Yahoo! Answers Food & Drink > Q&A._______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > ---------------------------------------------------------------------- > -----X---------------------------------------------------- > > Don't take life too seriously... > Nobody comes out alive anyway > _________________________________________________________________ > > Finding fabulous fares is fun. > [3]Let Yahoo! FareChase search your favorite travel sites to find > flight and hotel bargains. > > References > > 1. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 > 2. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 > 3. http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw-- > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 08:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWthe-0002Lc-QP; Thu, 29 Mar 2007 08:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWthd-0002LT-Ph for sigtran@ietf.org; Thu, 29 Mar 2007 08:26:05 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWthc-0001oU-JM for sigtran@ietf.org; Thu, 29 Mar 2007 08:26:05 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 00E5627AFC for ; Thu, 29 Mar 2007 07:26:00 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l2TCPxZP029004 for ; Thu, 29 Mar 2007 08:25:59 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sigtran] correct Error code Date: Thu, 29 Mar 2007 07:20:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <101728.67110.qm@web30013.mail.mud.yahoo.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Dario, "Invalid Routing Context" seems as a good choice. The RC is not defined for that particular peer, i.e. ASP. Thanks, Tolga -----Original Message----- From: Dario Filjar [mailto:dario_filjar@yahoo.com] Sent: Thursday, March 29, 2007 3:19 AM To: sigtran@ietf.org Subject: [Sigtran] correct Error code Hi, what would be the correct error code for the following situation: ASP ACTIVE is received at SGP with RC that is statically configured at SGP, but this RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE message. How SGP should respond? thanks in advance! Best regards, Dario _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 08:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWtsx-0000lw-0k; Thu, 29 Mar 2007 08:37:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWtsw-0000lh-LH for sigtran@ietf.org; Thu, 29 Mar 2007 08:37:46 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWtsu-0003j8-4S for sigtran@ietf.org; Thu, 29 Mar 2007 08:37:46 -0400 Received: from ns.pigworks.openss7.net (IDENT:Kt5+sA2FZwzHoqwmyVECLzAyuom5tPyi@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2TCbhs16006; Thu, 29 Mar 2007 06:37:43 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2TCbgH21814; Thu, 29 Mar 2007 06:37:42 -0600 Date: Thu, 29 Mar 2007 06:37:42 -0600 From: "Brian F. G. Bidulock" To: Tolga Asveren Subject: Re: [Sigtran] correct Error code Message-ID: <20070329063742.A21632@openss7.org> Mail-Followup-To: Tolga Asveren , sigtran@ietf.org References: <101728.67110.qm@web30013.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from asveren@ulticom.com on Thu, Mar 29, 2007 at 07:20:34AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Tolga, But that conflicts with the MUST requirementin RFC 4666. --brian Tolga Asveren wrote: (Thu, 29 Mar 2007 07:20:34) > Dario, > > "Invalid Routing Context" seems as a good choice. The RC is not defined for > that particular peer, i.e. ASP. > > Thanks, > Tolga > > -----Original Message----- > From: Dario Filjar [mailto:dario_filjar@yahoo.com] > Sent: Thursday, March 29, 2007 3:19 AM > To: sigtran@ietf.org > Subject: [Sigtran] correct Error code > > > Hi, > what would be the correct error code for the following situation: > ASP ACTIVE is received at SGP with RC that is statically configured at SGP, > but this > RC (AS) is not defined for particular ASP which has sent the ASP ACTIVE > message. > How SGP should respond? > thanks in advance! > > Best regards, Dario > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 08:54:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWu8h-0000jp-Qg; Thu, 29 Mar 2007 08:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWu8g-0000jj-Jz for sigtran@ietf.org; Thu, 29 Mar 2007 08:54:02 -0400 Received: from web50809.mail.re2.yahoo.com ([206.190.38.252]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWu8e-0006W2-2s for sigtran@ietf.org; Thu, 29 Mar 2007 08:54:02 -0400 Received: (qmail 98598 invoked by uid 60001); 29 Mar 2007 12:54:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=0zp2YZRJeajhtsF3btsBUBrsw98IoIb+WNpaAs7wj6GJkgFRTR53Ri5LcKKcw9Cd6iQOd+nOmOwg+JyLEPgZBa6hSi++HzNh+vKD7NLMnfzafH5wS7ofOqIdHIgDnvlZVGVUi5nvw2ivMIvoQ5IdVqBNc8XD3dXPKxvYEytp738=; X-YMail-OSG: 4RX96noVM1k_yjbocCsrkHqiWF5RMtk62ipEojrC Received: from [128.251.168.91] by web50809.mail.re2.yahoo.com via HTTP; Thu, 29 Mar 2007 05:53:59 PDT Date: Thu, 29 Mar 2007 05:53:59 -0700 (PDT) From: Aditya Subject: Re: [Sigtran] correct Error code To: bidulock@openss7.org In-Reply-To: <20070329053643.A18172@openss7.org> MIME-Version: 1.0 Message-ID: <958014.98318.qm@web50809.mail.re2.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0351997307==" Errors-To: sigtran-bounces@ietf.org --===============0351997307== Content-Type: multipart/alternative; boundary="0-1092018683-1175172839=:98318" Content-Transfer-Encoding: 8bit --0-1092018683-1175172839=:98318 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian, RFC 4666 mentions Invalid Routing Context to be sent if a message is received from a peer with an invalid(unconfigured) Routing Context value. Your analysis makes me think that only unconfigured RC is to be treated as Invalid. Isnt the RC invalid in the example mentioned below. I may be wrong but sending ERR management Locked message somehow does not inform the peer that there is something wrong at its end. IMHO, "Invalid Routing Context" seems like an appropriate message, since the RC is INVALID in this case. The RC being configured does not take away from the fact that it is invalid. Does RFC 4666 state anywhere that only unconfigured RC's are to be treated as Invalid? I mean, does it define Invalid RC in any sense. Aditya "Brian F. G. Bidulock" wrote: Aditya, Well.... RFC 4666 says: The "Invalid Routing Context" error is sent if a message is received from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid Routing Context(s) MUST be included in the Error message. In this case, the Routing Context value is configured. Also, RFC 4666 says: - If the RC parameter is included in the ASP Active message and the corresponding RK has been previously defined (by either static configuration or dynamic registration), the peer node MUST respond with an ASP Active Ack message. If for any local reason (e.g., management lockout) the SGP responds to an ASP Active message with an Error message with reason "Refused Management Blocking". So, in this case, the corresponding RK is configured by static configuration and the SGP has two choices: respond with ASP Active Ack, or response with ERR("Refused Management Blocking"). If the SGP does not wish to permit the ASP to activate for the AS, the proper error code is "Refused Management Blocking". --brian Aditya wrote: (Thu, 29 Mar 2007 02:07:05) > > Hi Dario, > The SGP should respond with Error "Invalid Routing Context" to the ASP > as the RC in question is not defined/configured for the ASP in > question. > Aditya > Dario Filjar wrote: > > Hi, > > what would be the correct error code for the following situation: > > ASP ACTIVE is received at SGP with RC that is statically configured at > SGP, but this > > RC (AS) is not defined for particular ASP which has sent the ASP > ACTIVE message. > > How SGP should respond? > > thanks in advance! > > > > Best regards, Dario > ______________________________________________________________ > > [1]Food fight? Enjoy some healthy debate > in the [2]Yahoo! Answers Food & Drink > Q&A._______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > > ---------------------------------------------------------------------- > -----X---------------------------------------------------- > > Don't take life too seriously... > Nobody comes out alive anyway > _________________________________________________________________ > > Finding fabulous fares is fun. > [3]Let Yahoo! FareChase search your favorite travel sites to find > flight and hotel bargains. > > References > > 1. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 > 2. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 > 3. http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw-- > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ ---------------------------------------------------------------------------X---------------------------------------------------- Don't take life too seriously... Nobody comes out alive anyway --------------------------------- Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. --0-1092018683-1175172839=:98318 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian,
RFC 4666 mentions Invalid Routing Context to be sent if a message is received from a peer with an invalid(unconfigured) Routing Context value. Your analysis makes me think that only unconfigured RC is to be treated as Invalid. Isnt the RC invalid in the example mentioned below.

I may be wrong but sending ERR management Locked message somehow does not inform the peer that there is something wrong at its end. IMHO, "Invalid Routing Context" seems like an appropriate message, since the RC is INVALID in this case. The RC being configured does not take away from the fact that it is invalid.

Does RFC 4666 state anywhere that only unconfigured RC's are to be treated as Invalid? I mean, does it define Invalid RC in any sense.

Aditya


"Brian F. G. Bidulock" <bidulock@openss7.org> wrote:
Aditya,

Well.... RFC 4666 says:

The "Invalid Routing Context" error is sent if a message is received
from a peer with an invalid (unconfigured) Routing Context value.
For this error, the invalid Routing Context(s) MUST be included in
the Error message.

In this case, the Routing Context value is configured.

Also, RFC 4666 says:

- If the RC parameter is included in the ASP Active message and the
corresponding RK has been previously defined (by either static
configuration or dynamic registration), the peer node MUST respond
with an ASP Active Ack message. If for any local reason (e.g.,
management lockout) the SGP responds to an ASP Active message with
an Error message with reason "Refused Management Blocking".

So, in this case, the corresponding RK is configured by static configuration
and the SGP has two choices: respond with ASP Active Ack, or response with
ERR("Refused Management Blocking"). If the SGP does not wish to permit the
ASP to activate for the AS, the proper error code is "Refused Management
Blocking".

--brian


Aditya wrote: (Thu, 29 Mar 2007 02:07:05)
>
> Hi Dario,
> The SGP should respond with Error "Invalid Routing Context" to the ASP
> as the RC in question is not defined/configured for the ASP in
> question.
> Aditya
> Dario Filjar wrote:
>
> Hi,
>
> what would be the correct error code for the following situation:
>
> ASP ACTIVE is received at SGP with RC that is statically configured at
> SGP, but this
>
> RC (AS) is not defined for particular ASP which has sent the ASP
> ACTIVE message.
>
> How SGP should respond?
>
> thanks in advance!
>
>
>
> Best regards, Dario
> ______________________________________________________________
>
> [1]Food fight? Enjoy some healthy debate
> in the [2]Yahoo! Answers Food & Drink
> Q&A._______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran
>
> ----------------------------------------------------------------------
> -----X----------------------------------------------------
>
> Don't take life too seriously...
> Nobody comes out alive anyway
> _________________________________________________________________
>
> Finding fabulous fares is fun.
> [3]Let Yahoo! FareChase search your favorite travel sites to find
> flight and hotel bargains.
>
> References
>
> 1. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
> 2. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
> 3. http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran


--
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/



---------------------------------------------------------------------------X----------------------------------------------------
 
Don't take life too seriously...
Nobody comes out alive anyway

Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta. --0-1092018683-1175172839=:98318-- --===============0351997307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0351997307==-- From sigtran-bounces@ietf.org Thu Mar 29 09:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWulH-00024e-DY; Thu, 29 Mar 2007 09:33:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWulF-0001o8-B4 for sigtran@ietf.org; Thu, 29 Mar 2007 09:33:53 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWulC-0004ld-PF for sigtran@ietf.org; Thu, 29 Mar 2007 09:33:53 -0400 Received: by an-out-0708.google.com with SMTP id d30so168281and for ; Thu, 29 Mar 2007 06:33:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nIX9k2/V4YT1OUiVuPZ4dmI2ASZqTBEdMoaZulWpVxvB6jafQkAtwUNcE1h+oACHYd6wiDbeWXtfA3k/7AXffaZyKzCOtlr/BydzFQT1RNon43ZU5c4zTuBRmck6PqKVv+mbGs40uHKwWWVbZ82YZQm9IeNq6T8ZwES5wAs8fO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=X5n9OvfDMrAkcGAfYAPoxTLsfFVYW1UpgdTKCFDTWDotV0yEFnZbV+hOWblp81hwvJ3xWPrb8AjzzaFbQ4xsGDNL7V+L57nIgeY6gF3xooDZ3yhJklI4iJu+JbD8aQWqyPdOkAd9D/J0uuMn4cD4YaUqbys3Qb74+J82ivr9YGE= Received: by 10.100.174.16 with SMTP id w16mr359753ane.1175175230461; Thu, 29 Mar 2007 06:33:50 -0700 (PDT) Received: by 10.100.154.5 with HTTP; Thu, 29 Mar 2007 06:33:50 -0700 (PDT) Message-ID: <6dbbbf160703290633n852fb96g1a529525244b060@mail.gmail.com> Date: Thu, 29 Mar 2007 14:33:50 +0100 From: "Ankit Kumar Sharma" To: bidulock@openss7.org, Aditya , "Dario Filjar" , sigtran@ietf.org Subject: Re: [Sigtran] correct Error code In-Reply-To: <20070329053643.A18172@openss7.org> MIME-Version: 1.0 References: <101728.67110.qm@web30013.mail.mud.yahoo.com> <369081.18973.qm@web50803.mail.re2.yahoo.com> <20070329053643.A18172@openss7.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0988498822==" Errors-To: sigtran-bounces@ietf.org --===============0988498822== Content-Type: multipart/alternative; boundary="----=_Part_30265_21542056.1175175230300" ------=_Part_30265_21542056.1175175230300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/29/07, Brian F. G. Bidulock wrote: > > Aditya, > > Well.... RFC 4666 says: > > The "Invalid Routing Context" error is sent if a message is received > from a peer with an invalid (unconfigured) Routing Context value. > For this error, the invalid Routing Context(s) MUST be included in > the Error message. In this case, the Routing Context value is configured. > > Also, RFC 4666 says: > > - If the RC parameter is included in the ASP Active message and the > corresponding RK has been previously defined (by either static > configuration or dynamic registration), the peer node MUST respond > with an ASP Active Ack message. If for any local reason (e.g., > management lockout) the SGP responds to an ASP Active message with > an Error message with reason "Refused Management Blocking". I think RFC is talking about the case in which ASP active contains a VALID RC value which is configured for the AS, whom this ASP wants to serve, at peer. So, in this case, the corresponding RK is configured by static configuration > and the SGP has two choices: respond with ASP Active Ack, or response with > ERR("Refused Management Blocking"). If the SGP does not wish to permit > the > ASP to activate for the AS, the proper error code is "Refused Management > Blocking". Error message with "Invalid routing context" ecode seems to be a better option because it clearly shows the cause. --brian > > > Aditya wrote: (Thu, 29 Mar 2007 > 02:07:05) > > > > Hi Dario, > > The SGP should respond with Error "Invalid Routing Context" to the > ASP > > as the RC in question is not defined/configured for the ASP > in > > question. > > Aditya > > Dario Filjar wrote: > > > > Hi, > > > > what would be the correct error code for the following situation: > > > > ASP ACTIVE is received at SGP with RC that is statically configured > at > > SGP, but this > > > > RC (AS) is not defined for particular ASP which has sent the > ASP > > ACTIVE message. > > > > How SGP should respond? > > > > thanks in advance! > > > > > > > > Best regards, Dario > > ______________________________________________________________ > > > > [1]Food fight? Enjoy some healthy debate > > in the [2]Yahoo! Answers Food & Drink > > Q&A._______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > ---------------------------------------------------------------------- > > -----X---------------------------------------------------- > > > > Don't take life too seriously... > > Nobody comes out alive anyway > > _________________________________________________________________ > > > > Finding fabulous fares is fun. > > [3]Let Yahoo! FareChase search your favorite travel sites to > find > > flight and hotel bargains. > > > > References > > > > 1. > http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 > > 2. > http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367 > > 3. > http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw-- > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > ------=_Part_30265_21542056.1175175230300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 3/29/07, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
Aditya,

Well....  RFC 4666 says:

   The "Invalid Routing Context" error is sent if a message is received
   from a peer with an invalid (unconfigured) Routing Context value.
   For this error, the invalid Routing Context(s) MUST be included in
   the Error message.
 

In this case, the Routing Context value is configured.

Also, RFC 4666 says:

   - If the RC parameter is included in the ASP Active message and the
     corresponding RK has been previously defined (by either static
     configuration or dynamic registration), the peer node MUST respond
     with an ASP Active Ack message.  If for any local reason (e.g.,
     management lockout) the SGP responds to an ASP Active message with
     an Error message with reason "Refused Management Blocking".

I think RFC is talking about the case in which ASP active contains a VALID RC value which is configured for the AS, whom this ASP wants to serve, at peer.

So, in this case, the corresponding RK is configured by static configuration
and the SGP has two choices: respond with ASP Active Ack, or response with
ERR("Refused Management Blocking").  If the SGP does not wish to permit the
ASP to activate for the AS, the proper error code is "Refused Management
Blocking".

Error message with "Invalid routing context" ecode seems to be a better option because it clearly shows the cause.

--brian


Aditya wrote:                                      (Thu, 29 Mar 2007 02:07:05)
>
>    Hi Dario,
>    The SGP should respond with Error "Invalid Routing Context" to the ASP
>    as  the  RC  in  question  is  not  defined/configured  for the ASP in
>    question.
>    Aditya
>    Dario Filjar <dario_filjar@yahoo.com> wrote:
>
>    Hi,
>
>    what would be the correct error code for the following situation:
>
>    ASP ACTIVE is received at SGP with RC that is statically configured at
>    SGP, but this
>
>    RC  (AS)  is  not  defined  for  particular ASP which has sent the ASP
>    ACTIVE message.
>
>    How SGP should respond?
>
>    thanks in advance!
>
>
>
>    Best regards, Dario
>        ______________________________________________________________
>
>      [1]Food fight? Enjoy some healthy debate
>      in the [2]Yahoo! Answers Food & Drink
>      Q&A._______________________________________________
>      Sigtran mailing list
>       Sigtran@ietf.org
>      https://www1.ietf.org/mailman/listinfo/sigtran
>
>    ----------------------------------------------------------------------
>    -----X----------------------------------------------------
>
>    Don't take life too seriously...
>    Nobody comes out alive anyway
>      _________________________________________________________________
>
>    Finding fabulous fares is fun.
>    [3]Let  Yahoo!  FareChase  search  your  favorite travel sites to find
>    flight and hotel bargains.
>
> References
>
>    1. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
>    2. http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367
>    3. http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran


--
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran

------=_Part_30265_21542056.1175175230300-- --===============0988498822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0988498822==-- From sigtran-bounces@ietf.org Thu Mar 29 09:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuqv-00077P-1b; Thu, 29 Mar 2007 09:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuqt-00077K-Qc for sigtran@ietf.org; Thu, 29 Mar 2007 09:39:43 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWuqs-0005il-Dk for sigtran@ietf.org; Thu, 29 Mar 2007 09:39:43 -0400 Received: from ns.pigworks.openss7.net (IDENT:+/65ELvDWE5Ew83y81MetpZdNPvQPiqu@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2TDdfs17769; Thu, 29 Mar 2007 07:39:41 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2TDdfA22911; Thu, 29 Mar 2007 07:39:41 -0600 Date: Thu, 29 Mar 2007 07:39:41 -0600 From: "Brian F. G. Bidulock" To: Aditya Subject: Re: [Sigtran] correct Error code Message-ID: <20070329073941.A22832@openss7.org> Mail-Followup-To: Aditya , sigtran@ietf.org References: <20070329053643.A18172@openss7.org> <958014.98318.qm@web50809.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <958014.98318.qm@web50809.mail.re2.yahoo.com>; from adityasehgal@yahoo.com on Thu, Mar 29, 2007 at 05:53:59AM -0700 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Aditya, The RC is not invalid: the ASP is merely not permitted to activate for it. In this case it is management blocked. The peer should be welcome to retry, because at some point in the future it might be permitted to activate for the AS (e.g. the permission might have only been revoked temporarily). Sending "Invalid Routing Context" would make the peer believe that the corresponding RK is not provisioned (which it is) and might result in a dynamic registration attempt (which is inappropriate). Besides, if "Invalid Routing Context" is returned, it violates the MUST in this passage: > - If the RC parameter is included in the ASP Active message and the > corresponding RK has been previously defined (by either static > configuration or dynamic registration), the peer node MUST respond > with an ASP Active Ack message. If for any local reason (e.g., > management lockout) the SGP responds to an ASP Active message with > an Error message with reason "Refused Management Blocking". --brian Aditya wrote: (Thu, 29 Mar 2007 05:53:59) > > Brian, > RFC 4666 mentions Invalid Routing Context to be sent if a message is > received from a peer with an invalid(unconfigured) Routing Context > value. Your analysis makes me think that only unconfigured RC is to be > treated as Invalid. Isnt the RC invalid in the example mentioned > below. > I may be wrong but sending ERR management Locked message somehow does > not inform the peer that there is something wrong at its end. IMHO, > "Invalid Routing Context" seems like an appropriate message, since the > RC is INVALID in this case. The RC being configured does not take away > from the fact that it is invalid. > Does RFC 4666 state anywhere that only unconfigured RC's are to be > treated as Invalid? I mean, does it define Invalid RC in any sense. > Aditya -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 09:43:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuu1-00084j-6T; Thu, 29 Mar 2007 09:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWutz-00084a-Ha for sigtran@ietf.org; Thu, 29 Mar 2007 09:42:55 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWutw-0006nq-NG for sigtran@ietf.org; Thu, 29 Mar 2007 09:42:55 -0400 Received: from ns.pigworks.openss7.net (IDENT:iH/mYRH9G4YmdWwUPEyioC3ahdqr43Uh@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2TDgps17872; Thu, 29 Mar 2007 07:42:51 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2TDgpW22977; Thu, 29 Mar 2007 07:42:51 -0600 Date: Thu, 29 Mar 2007 07:42:51 -0600 From: "Brian F. G. Bidulock" To: Ankit Kumar Sharma Subject: Re: [Sigtran] correct Error code Message-ID: <20070329074251.B22832@openss7.org> Mail-Followup-To: Ankit Kumar Sharma , Aditya , Dario Filjar , sigtran@ietf.org References: <101728.67110.qm@web30013.mail.mud.yahoo.com> <369081.18973.qm@web50803.mail.re2.yahoo.com> <20070329053643.A18172@openss7.org> <6dbbbf160703290633n852fb96g1a529525244b060@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6dbbbf160703290633n852fb96g1a529525244b060@mail.gmail.com>; from ankisharma@gmail.com on Thu, Mar 29, 2007 at 02:33:50PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Ankit, Ankit Kumar Sharma wrote: (Thu, 29 Mar 2007 14:33:50) > Also, RFC 4666 says: > - If the RC parameter is included in the ASP Active message and the > corresponding RK has been previously defined (by either static > configuration or dynamic registration), the peer node MUST respond > with an ASP Active Ack message. If for any local reason (e.g., > management lockout) the SGP responds to an ASP Active message with > an Error message with reason "Refused Management Blocking". > > I think RFC is talking about the case in which ASP active contains a > VALID RC value which is configured for the AS, whom this ASP wants to > serve, at peer. The RC value is valid (there is a corresponding RK defined by static configuration). > > Error message with "Invalid routing context" ecode seems to be a > better option because it clearly shows the cause. But is forbidden by the RFC in this case. Besides it is incorrect because the RC is valid, (just not permitted). --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 09:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv5j-0000HC-Iq; Thu, 29 Mar 2007 09:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv5i-0000Gb-CH for sigtran@ietf.org; Thu, 29 Mar 2007 09:55:02 -0400 Received: from ottawa.pt.com ([209.217.107.194] helo=grandpa.ottawa.pt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWv5X-0000Mc-RH for sigtran@ietf.org; Thu, 29 Mar 2007 09:54:53 -0400 Received: from [10.81.15.50] (unknown [10.81.15.50]) by grandpa.ottawa.pt.com (Postfix) with ESMTP id 88BEAD71A0; Thu, 29 Mar 2007 09:48:31 -0400 (EDT) Message-ID: <460BC529.3020105@pt.com> Date: Thu, 29 Mar 2007 09:54:49 -0400 From: Andrew Booth User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Aditya , sigtran@ietf.org Subject: Re: [Sigtran] correct Error code References: <20070329053643.A18172@openss7.org> <958014.98318.qm@web50809.mail.re2.yahoo.com> <20070329073941.A22832@openss7.org> In-Reply-To: <20070329073941.A22832@openss7.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi, I agree with Brian. The RC is not invalid, the SGP is just refusing the ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. As an aside, I think the text of the pertinent paragraph is missing something. The meaning is fairly clear, but it should probably read: If for any local reason the SGP will not act on the ASP ACTIVE request (e.g., management lockout) the SGP responds to an ASP Active message with an Error message with reason "Refused Management Blocking". Andrew Brian F. G. Bidulock wrote: > Aditya, > > The RC is not invalid: the ASP is merely not permitted to activate for it. > In this case it is management blocked. The peer should be welcome to > retry, because at some point in the future it might be permitted to activate > for the AS (e.g. the permission might have only been revoked temporarily). > Sending "Invalid Routing Context" would make the peer believe that the > corresponding RK is not provisioned (which it is) and might result in a > dynamic registration attempt (which is inappropriate). > > Besides, if "Invalid Routing Context" is returned, it violates the MUST in > this passage: > > >> - If the RC parameter is included in the ASP Active message and the >> corresponding RK has been previously defined (by either static >> configuration or dynamic registration), the peer node MUST respond >> with an ASP Active Ack message. If for any local reason (e.g., >> management lockout) the SGP responds to an ASP Active message with >> an Error message with reason "Refused Management Blocking". >> > > --brian > > Aditya wrote: (Thu, 29 Mar 2007 05:53:59) > >> Brian, >> RFC 4666 mentions Invalid Routing Context to be sent if a message is >> received from a peer with an invalid(unconfigured) Routing Context >> value. Your analysis makes me think that only unconfigured RC is to be >> treated as Invalid. Isnt the RC invalid in the example mentioned >> below. >> I may be wrong but sending ERR management Locked message somehow does >> not inform the peer that there is something wrong at its end. IMHO, >> "Invalid Routing Context" seems like an appropriate message, since the >> RC is INVALID in this case. The RC being configured does not take away >> from the fact that it is invalid. >> Does RFC 4666 state anywhere that only unconfigured RC's are to be >> treated as Invalid? I mean, does it define Invalid RC in any sense. >> Aditya >> > > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 10:16:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvQ4-0006Pz-VR; Thu, 29 Mar 2007 10:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvQ3-0006Mt-L6 for sigtran@ietf.org; Thu, 29 Mar 2007 10:16:03 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvQ2-00034i-9O for sigtran@ietf.org; Thu, 29 Mar 2007 10:16:03 -0400 Received: by an-out-0708.google.com with SMTP id d30so180126and for ; Thu, 29 Mar 2007 07:16:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=H1GuasOzAfpBVRl3B+4lv2PdL+PEJUmV5/TuKdnkeF9DwqY3fYNbkvC/sLkkRr6yW9wYinjWSmALliai85bUYtA22JHb8qywmb9nGe9mhN18L94cnL+olqiFv0ZU43KgKghmBgO5yUZmCvtKGmylqVsUmL+E8kou4p59LBregrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nOH2QUKXLvEYwnXztOAYNoOgrajVmksTHwDqLDauKCtDZDdfOzm59xw9oIbLMmHLJED2cGuq5+l4N9GYjnexPw7UrniRhABuQDiFh+FVSvJgVlX/nkFKzQJeLCpD/u7v2xNgdMuD6tVRghpR8GZV3WStZC10M5y/JBqidcAKUus= Received: by 10.100.91.6 with SMTP id o6mr397367anb.1175177761624; Thu, 29 Mar 2007 07:16:01 -0700 (PDT) Received: by 10.100.154.5 with HTTP; Thu, 29 Mar 2007 07:16:01 -0700 (PDT) Message-ID: <6dbbbf160703290716y79ab0106p1fc0ebd757f3d7c4@mail.gmail.com> Date: Thu, 29 Mar 2007 15:16:01 +0100 From: "Ankit Kumar Sharma" To: bidulock@openss7.org, "Ankit Kumar Sharma" , Aditya , "Dario Filjar" , sigtran@ietf.org Subject: Re: [Sigtran] correct Error code In-Reply-To: <20070329074251.B22832@openss7.org> MIME-Version: 1.0 References: <101728.67110.qm@web30013.mail.mud.yahoo.com> <369081.18973.qm@web50803.mail.re2.yahoo.com> <20070329053643.A18172@openss7.org> <6dbbbf160703290633n852fb96g1a529525244b060@mail.gmail.com> <20070329074251.B22832@openss7.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0271266142==" Errors-To: sigtran-bounces@ietf.org --===============0271266142== Content-Type: multipart/alternative; boundary="----=_Part_31197_9917239.1175177761568" ------=_Part_31197_9917239.1175177761568 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Brian, On 3/29/07, Brian F. G. Bidulock wrote: > > Ankit, > > Ankit Kumar Sharma wrote: (Thu, 29 Mar 2007 > 14:33:50) > > > Also, RFC 4666 says: > > - If the RC parameter is included in the ASP Active message and > the > > corresponding RK has been previously defined (by either static > > configuration or dynamic registration), the peer node MUST > respond > > with an ASP Active Ack message. If for any local reason > (e.g., > > management lockout) the SGP responds to an ASP Active message > with > > an Error message with reason "Refused Management Blocking". > > > > I think RFC is talking about the case in which ASP active contains > a > > VALID RC value which is configured for the AS, whom this ASP wants > to > > serve, at peer. > > The RC value is valid (there is a corresponding RK defined by static > configuration). > > > > > Error message with "Invalid routing context" ecode seems to be > a > > better option because it clearly shows the cause. > > But is forbidden by the RFC in this case. Besides it is incorrect because > the RC is valid, (just not permitted). I somewhat agree with you but I still feel that 'valid' and 'configured' are two different things. If a RC is configured for an AS then it is not valid for any xyz ASP(which has to serve different AS) to send ASP-ACTIVE with this RC. Purpose of any error code is to let the user correct the cause of error quickly. If i go by your words i.e reply with ecode "..Blocking" then originator of ASP-AC could think that his message is perfect but for some, unknown, local reason peer is not allowing this ASP to become active. Whereas, if we reply with "inv...context" ecode then originator could quickly check on the RC value to make it's ASP Active. --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > ------=_Part_31197_9917239.1175177761568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Brian,

On 3/29/07, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
Ankit,

Ankit Kumar Sharma wrote:                          (Thu, 29 Mar 2007 14:33:50)

>      Also, RFC 4666 says:
>          - If the RC parameter is included in the ASP Active message and the
>           corresponding RK has been previously defined (by either static
>            configuration  or  dynamic  registration), the peer node MUST respond
>            with  an  ASP  Active  Ack  message.  If for any local reason (e.g.,
>            management lockout) the SGP responds to an ASP Active message with
>           an Error message with reason "Refused Management Blocking".
>
>    I  think  RFC is talking about the case in which ASP active contains a
>    VALID  RC value which is configured for the AS, whom this ASP wants to
>    serve, at peer.

The RC value is valid (there is a corresponding RK defined by static
configuration).

>
>    Error  message  with  "Invalid  routing  context"  ecode seems to be a
>    better option because it clearly shows the cause.

But is forbidden by the RFC in this case.  Besides it is incorrect because
the RC is valid, (just not permitted). 

I somewhat agree with you but I still feel that 'valid' and 'configured' are two different things. If a RC is configured for an AS then it is not valid for any xyz ASP(which has to serve different AS) to send ASP-ACTIVE with this RC.
Purpose of any error code is to let the user correct the cause of error quickly. If i go by your words i.e reply with ecode "..Blocking" then originator of ASP-AC could think that his message is perfect but for some, unknown, local reason peer is not allowing this ASP to become active. Whereas, if we reply with "inv...context" ecode then originator could quickly check on the RC value to make it's ASP Active.

--brian

--
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

------=_Part_31197_9917239.1175177761568-- --===============0271266142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0271266142==-- From sigtran-bounces@ietf.org Thu Mar 29 10:28:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvbj-0003Bj-8Z; Thu, 29 Mar 2007 10:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvbh-00038E-WA for sigtran@ietf.org; Thu, 29 Mar 2007 10:28:06 -0400 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvbg-00052t-Ic for sigtran@ietf.org; Thu, 29 Mar 2007 10:28:05 -0400 Received: from ns.pigworks.openss7.net (IDENT:iPIosgJZUAkO2gX+PrpZDf6SiIQVPc13@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l2TES3s19371; Thu, 29 Mar 2007 08:28:03 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l2TES3I23869; Thu, 29 Mar 2007 08:28:03 -0600 Date: Thu, 29 Mar 2007 08:28:02 -0600 From: "Brian F. G. Bidulock" To: Ankit Kumar Sharma Subject: Re: [Sigtran] correct Error code Message-ID: <20070329082802.A23571@openss7.org> Mail-Followup-To: Ankit Kumar Sharma , Aditya , Dario Filjar , sigtran@ietf.org References: <101728.67110.qm@web30013.mail.mud.yahoo.com> <369081.18973.qm@web50803.mail.re2.yahoo.com> <20070329053643.A18172@openss7.org> <6dbbbf160703290633n852fb96g1a529525244b060@mail.gmail.com> <20070329074251.B22832@openss7.org> <6dbbbf160703290716y79ab0106p1fc0ebd757f3d7c4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6dbbbf160703290716y79ab0106p1fc0ebd757f3d7c4@mail.gmail.com>; from ankisharma@gmail.com on Thu, Mar 29, 2007 at 03:16:01PM +0100 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Ankit, Ankit Kumar Sharma wrote: (Thu, 29 Mar 2007 15:16:01) > > I somewhat agree with you but I still feel that 'valid' and > 'configured' are two different things. If a RC is configured for an AS > then it is not valid for any xyz ASP(which has to serve different AS) > to send ASP-ACTIVE with this RC. The paragraph with the "MUST" in it does not agree with you. For the supplied RC, if a "corresponding RK has been previously defined (by either static configuration or dynamic registration)" then you are prohibited from sending ERR("Invalid Routing Context"). This means that 'valid' and 'configured' are the same thing. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 11:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwdn-0001Yk-BN; Thu, 29 Mar 2007 11:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwdm-0001Yf-9d for sigtran@ietf.org; Thu, 29 Mar 2007 11:34:18 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwdk-0000hP-S5 for sigtran@ietf.org; Thu, 29 Mar 2007 11:34:18 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 8E4870B6B1 for ; Thu, 29 Mar 2007 10:34:03 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l2TFXwVp008052 for ; Thu, 29 Mar 2007 11:34:03 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sigtran] correct Error code Date: Thu, 29 Mar 2007 10:28:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <460BC529.3020105@pt.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org If RC is configured statically per ASP on SGP, I wouldn't think it is wrong to say that it is invalid for that particular ASP. The peers are ASPs and SGPs in that relationship. Thanks, Tolga > -----Original Message----- > From: Andrew Booth [mailto:abooth@pt.com] > Sent: Thursday, March 29, 2007 8:55 AM > To: Aditya; sigtran@ietf.org > Subject: Re: [Sigtran] correct Error code > > > Hi, > > I agree with Brian. The RC is not invalid, the SGP is just refusing the > ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. > > As an aside, I think the text of the pertinent paragraph is missing > something. The meaning is fairly clear, but it should probably read: > > If for any local reason the SGP will not act on the ASP ACTIVE request > (e.g., management lockout) the SGP responds to an ASP Active message > with an Error message with reason "Refused Management Blocking". > > Andrew > > Brian F. G. Bidulock wrote: > > Aditya, > > > > The RC is not invalid: the ASP is merely not permitted to > activate for it. > > In this case it is management blocked. The peer should be welcome to > > retry, because at some point in the future it might be > permitted to activate > > for the AS (e.g. the permission might have only been revoked > temporarily). > > Sending "Invalid Routing Context" would make the peer believe that the > > corresponding RK is not provisioned (which it is) and might result in a > > dynamic registration attempt (which is inappropriate). > > > > Besides, if "Invalid Routing Context" is returned, it violates > the MUST in > > this passage: > > > > > >> - If the RC parameter is included in the ASP Active > message and the > >> corresponding RK has been previously defined (by either static > >> configuration or dynamic registration), the peer node MUST respond > >> with an ASP Active Ack message. If for any local reason (e.g., > >> management lockout) the SGP responds to an ASP Active message with > >> an Error message with reason "Refused Management Blocking". > >> > > > > --brian > > > > Aditya wrote: (Thu, 29 Mar > 2007 05:53:59) > > > >> Brian, > >> RFC 4666 mentions Invalid Routing Context to be sent if a > message is > >> received from a peer with an invalid(unconfigured) > Routing Context > >> value. Your analysis makes me think that only unconfigured > RC is to be > >> treated as Invalid. Isnt the RC invalid in the > example mentioned > >> below. > >> I may be wrong but sending ERR management Locked message > somehow does > >> not inform the peer that there is something wrong at its > end. IMHO, > >> "Invalid Routing Context" seems like an appropriate > message, since the > >> RC is INVALID in this case. The RC being configured does > not take away > >> from the fact that it is invalid. > >> Does RFC 4666 state anywhere that only unconfigured > RC's are to be > >> treated as Invalid? I mean, does it define Invalid RC in any sense. > >> Aditya > >> > > > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 15:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX069-0005c8-6H; Thu, 29 Mar 2007 15:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX068-0005Vo-8u for sigtran@ietf.org; Thu, 29 Mar 2007 15:15:48 -0400 Received: from web50809.mail.re2.yahoo.com ([206.190.38.252]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWzvd-0007M7-7t for sigtran@ietf.org; Thu, 29 Mar 2007 15:04:59 -0400 Received: (qmail 58648 invoked by uid 60001); 29 Mar 2007 19:04:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=XadYIksUx6AwoufSrZkQrMEg9RFJ1t1wT2ybpJ0qpLRJYvcmWCuxXVQgjH1eiAz/f/XAWLT9E7CS+27C6zpgbGorK+3z5MaTHVvc6rngE9WJ381oanWytGuzb+gSBGqcaMxdZlYxggsFS6vTQ/gbykEKRzsshsOCBRQqUBIxmE4=; X-YMail-OSG: AI2pOjgVM1lcsjeWc1BgclSx8OULvaBxXaPk.vWb Received: from [122.163.220.117] by web50809.mail.re2.yahoo.com via HTTP; Thu, 29 Mar 2007 12:04:56 PDT Date: Thu, 29 Mar 2007 12:04:56 -0700 (PDT) From: Aditya Subject: RE: [Sigtran] correct Error code To: sigtran@ietf.org In-Reply-To: MIME-Version: 1.0 Message-ID: <93013.58641.qm@web50809.mail.re2.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0389947498==" Errors-To: sigtran-bounces@ietf.org --===============0389947498== Content-Type: multipart/alternative; boundary="0-696688988-1175195096=:58641" Content-Transfer-Encoding: 8bit --0-696688988-1175195096=:58641 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian, Although, I agree with your analysis in principle, I still feel sending ERR message with cause "Management Locked" does not provide a true picture in all cases. It might work in the case you described, but what about a case where configuration of RC's mapping to AS is wrong by mistake. The peer will never come to know that the configuration at its end is wrong and will be made to believe that somethings not right at the other end. An error message with cause "invalid Routing context" seems more appropriate then. Aditya Tolga Asveren wrote: If RC is configured statically per ASP on SGP, I wouldn't think it is wrong to say that it is invalid for that particular ASP. The peers are ASPs and SGPs in that relationship. Thanks, Tolga > -----Original Message----- > From: Andrew Booth [mailto:abooth@pt.com] > Sent: Thursday, March 29, 2007 8:55 AM > To: Aditya; sigtran@ietf.org > Subject: Re: [Sigtran] correct Error code > > > Hi, > > I agree with Brian. The RC is not invalid, the SGP is just refusing the > ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. > > As an aside, I think the text of the pertinent paragraph is missing > something. The meaning is fairly clear, but it should probably read: > > If for any local reason the SGP will not act on the ASP ACTIVE request > (e.g., management lockout) the SGP responds to an ASP Active message > with an Error message with reason "Refused Management Blocking". > > Andrew > > Brian F. G. Bidulock wrote: > > Aditya, > > > > The RC is not invalid: the ASP is merely not permitted to > activate for it. > > In this case it is management blocked. The peer should be welcome to > > retry, because at some point in the future it might be > permitted to activate > > for the AS (e.g. the permission might have only been revoked > temporarily). > > Sending "Invalid Routing Context" would make the peer believe that the > > corresponding RK is not provisioned (which it is) and might result in a > > dynamic registration attempt (which is inappropriate). > > > > Besides, if "Invalid Routing Context" is returned, it violates > the MUST in > > this passage: > > > > > >> - If the RC parameter is included in the ASP Active > message and the > >> corresponding RK has been previously defined (by either static > >> configuration or dynamic registration), the peer node MUST respond > >> with an ASP Active Ack message. If for any local reason (e.g., > >> management lockout) the SGP responds to an ASP Active message with > >> an Error message with reason "Refused Management Blocking". > >> > > > > --brian > > > > Aditya wrote: (Thu, 29 Mar > 2007 05:53:59) > > > >> Brian, > >> RFC 4666 mentions Invalid Routing Context to be sent if a > message is > >> received from a peer with an invalid(unconfigured) > Routing Context > >> value. Your analysis makes me think that only unconfigured > RC is to be > >> treated as Invalid. Isnt the RC invalid in the > example mentioned > >> below. > >> I may be wrong but sending ERR management Locked message > somehow does > >> not inform the peer that there is something wrong at its > end. IMHO, > >> "Invalid Routing Context" seems like an appropriate > message, since the > >> RC is INVALID in this case. The RC being configured does > not take away > >> from the fact that it is invalid. > >> Does RFC 4666 state anywhere that only unconfigured > RC's are to be > >> treated as Invalid? I mean, does it define Invalid RC in any sense. > >> Aditya > >> > > > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran ---------------------------------------------------------------------------X---------------------------------------------------- Don't take life too seriously... Nobody comes out alive anyway --------------------------------- We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. --0-696688988-1175195096=:58641 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Brian,
Although, I agree with your analysis in principle, I still feel sending ERR message with cause "Management Locked" does not provide a true picture in all cases. It might work in the case you described, but what about a case where configuration of RC's mapping to AS is wrong by mistake.

The peer will never come to know that the configuration at its end is wrong and will be made to believe that somethings not right at the other end.

An error message with cause "invalid Routing context" seems more appropriate then.

Aditya

Tolga Asveren <asveren@ulticom.com> wrote:
If RC is configured statically per ASP on SGP, I wouldn't think it is wrong
to say that it is invalid for that particular ASP. The peers are ASPs and
SGPs in that relationship.

Thanks,
Tolga

> -----Original Message-----
> From: Andrew Booth [mailto:abooth@pt.com]
> Sent: Thursday, March 29, 2007 8:55 AM
> To: Aditya; sigtran@ietf.org
> Subject: Re: [Sigtran] correct Error code
>
>
> Hi,
>
> I agree with Brian. The RC is not invalid, the SGP is just refusing the
> ASP ACTIVE. Hence "Refused Management Blocking" is appropriate.
>
> As an aside, I think the text of the pertinent paragraph is missing
> something. The meaning is fairly clear, but it should probably read:
>
> If for any local reason the SGP will not act on the ASP ACTIVE request
> (e.g., management lockout) the SGP responds to an ASP Active message
> with an Error message with reason "Refused Management Blocking".
>
> Andrew
>
> Brian F. G. Bidulock wrote:
> > Aditya,
> >
> > The RC is not invalid: the ASP is merely not permitted to
> activate for it.
> > In this case it is management blocked. The peer should be welcome to
> > retry, because at some point in the future it might be
> permitted to activate
> > for the AS (e.g. the permission might have only been revoked
> temporarily).
> > Sending "Invalid Routing Context" would make the peer believe that the
> > corresponding RK is not provisioned (which it is) and might result in a
> > dynamic registration attempt (which is inappropriate).
> >
> > Besides, if "Invalid Routing Context" is returned, it violates
> the MUST in
> > this passage:
> >
> >
> >> - If the RC parameter is included in the ASP Active
> message and the
> >> corresponding RK has been previously defined (by either static
> >> configuration or dynamic registration), the peer node MUST respond
> >> with an ASP Active Ack message. If for any local reason (e.g.,
> >> management lockout) the SGP responds to an ASP Active message with
> >> an Error message with reason "Refused Management Blocking".
> >>
> >
> > --brian
> >
> > Aditya wrote: (Thu, 29 Mar
> 2007 05:53:59)
> >
> >> Brian,
> >> RFC 4666 mentions Invalid Routing Context to be sent if a
> message is
> >> received from a peer with an invalid(unconfigured)
> Routing Context
> >> value. Your analysis makes me think that only unconfigured
> RC is to be
> >> treated as Invalid. Isnt the RC invalid in the
> example mentioned
> >> below.
> >> I may be wrong but sending ERR management Locked message
> somehow does
> >> not inform the peer that there is something wrong at its
> end. IMHO,
> >> "Invalid Routing Context" seems like an appropriate
> message, since the
> >> RC is INVALID in this case. The RC being configured does
> not take away
> >> from the fact that it is invalid.
> >> Does RFC 4666 state anywhere that only unconfigured
> RC's are to be
> >> treated as Invalid? I mean, does it define Invalid RC in any sense.
> >> Aditya
> >>
> >
> >
> >
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran


_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran



---------------------------------------------------------------------------X----------------------------------------------------
 
Don't take life too seriously...
Nobody comes out alive anyway

We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list. --0-696688988-1175195096=:58641-- --===============0389947498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran --===============0389947498==-- From sigtran-bounces@ietf.org Thu Mar 29 15:33:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0ML-0003ZB-5W; Thu, 29 Mar 2007 15:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0MJ-0003Yx-Gb for sigtran@ietf.org; Thu, 29 Mar 2007 15:32:31 -0400 Received: from ottawa.pt.com ([209.217.107.194] helo=grandpa.ottawa.pt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0MI-0003Yc-5k for sigtran@ietf.org; Thu, 29 Mar 2007 15:32:31 -0400 Received: from [10.81.15.50] (unknown [10.81.15.50]) by grandpa.ottawa.pt.com (Postfix) with ESMTP id 4FAD8D71A6; Thu, 29 Mar 2007 15:26:10 -0400 (EDT) Message-ID: <460C1449.7060105@pt.com> Date: Thu, 29 Mar 2007 15:32:25 -0400 From: Andrew Booth User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Sigtran] correct Error code References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi Tolga, It's a subtle point about the definitions. My personal views are unchanged, but I think this argument is being addressed in the other branch of this thread. My intended contribution just that the RFC appears to have some text missing in one of the critical passages, that could perhaps be addressed if there is ever another rev of M3UA. Andrew Tolga Asveren wrote: > If RC is configured statically per ASP on SGP, I wouldn't think it is wrong > to say that it is invalid for that particular ASP. The peers are ASPs and > SGPs in that relationship. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Andrew Booth [mailto:abooth@pt.com] >> Sent: Thursday, March 29, 2007 8:55 AM >> To: Aditya; sigtran@ietf.org >> Subject: Re: [Sigtran] correct Error code >> >> >> Hi, >> >> I agree with Brian. The RC is not invalid, the SGP is just refusing the >> ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. >> >> As an aside, I think the text of the pertinent paragraph is missing >> something. The meaning is fairly clear, but it should probably read: >> >> If for any local reason the SGP will not act on the ASP ACTIVE request >> (e.g., management lockout) the SGP responds to an ASP Active message >> with an Error message with reason "Refused Management Blocking". >> >> Andrew >> >> Brian F. G. Bidulock wrote: >> >>> Aditya, >>> >>> The RC is not invalid: the ASP is merely not permitted to >>> >> activate for it. >> >>> In this case it is management blocked. The peer should be welcome to >>> retry, because at some point in the future it might be >>> >> permitted to activate >> >>> for the AS (e.g. the permission might have only been revoked >>> >> temporarily). >> >>> Sending "Invalid Routing Context" would make the peer believe that the >>> corresponding RK is not provisioned (which it is) and might result in a >>> dynamic registration attempt (which is inappropriate). >>> >>> Besides, if "Invalid Routing Context" is returned, it violates >>> >> the MUST in >> >>> this passage: >>> >>> >>> >>>> - If the RC parameter is included in the ASP Active >>>> >> message and the >> >>>> corresponding RK has been previously defined (by either static >>>> configuration or dynamic registration), the peer node MUST respond >>>> with an ASP Active Ack message. If for any local reason (e.g., >>>> management lockout) the SGP responds to an ASP Active message with >>>> an Error message with reason "Refused Management Blocking". >>>> >>>> >>> --brian >>> >>> Aditya wrote: (Thu, 29 Mar >>> >> 2007 05:53:59) >> >>>> Brian, >>>> RFC 4666 mentions Invalid Routing Context to be sent if a >>>> >> message is >> >>>> received from a peer with an invalid(unconfigured) >>>> >> Routing Context >> >>>> value. Your analysis makes me think that only unconfigured >>>> >> RC is to be >> >>>> treated as Invalid. Isnt the RC invalid in the >>>> >> example mentioned >> >>>> below. >>>> I may be wrong but sending ERR management Locked message >>>> >> somehow does >> >>>> not inform the peer that there is something wrong at its >>>> >> end. IMHO, >> >>>> "Invalid Routing Context" seems like an appropriate >>>> >> message, since the >> >>>> RC is INVALID in this case. The RC being configured does >>>> >> not take away >> >>>> from the fact that it is invalid. >>>> Does RFC 4666 state anywhere that only unconfigured >>>> >> RC's are to be >> >>>> treated as Invalid? I mean, does it define Invalid RC in any sense. >>>> Aditya >>>> >>>> >>> >>> >> _______________________________________________ >> Sigtran mailing list >> Sigtran@ietf.org >> https://www1.ietf.org/mailman/listinfo/sigtran >> > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 15:53:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0fb-0003fc-0v; Thu, 29 Mar 2007 15:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0fY-0003Zz-J9 for sigtran@ietf.org; Thu, 29 Mar 2007 15:52:24 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0av-0005BU-VC for sigtran@ietf.org; Thu, 29 Mar 2007 15:47:39 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 7A5FA20D36; Thu, 29 Mar 2007 14:47:24 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l2TJlNZ0016938; Thu, 29 Mar 2007 15:47:24 -0400 (EDT) From: "Tolga Asveren" To: "Andrew Booth" Subject: RE: [Sigtran] correct Error code Date: Thu, 29 Mar 2007 14:41:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <460C1449.7060105@pt.com> Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: sigtran@ietf.org X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Hi Andrew, I don't think it is addressed :-). The point I tried to make was, if RC is configured per ASP, considering RC values for other ASPs as the the "same" RC doesn't sound correct. For example: +-------+ +-------+ | ASP1 | | ASP2 | +------++ ++------+ | | | | | | | | | | ++-----++ | SGP | +-------+ Configuration for ASP1: RC1: DPC=1-1-1, RC=1 Configuration for ASP2: RC2: DPC=2-2-2 RC=1 RC1 and RC2 are using the same "RC" value but they are not referring to the same RK. Basically, the concept of "RC being defined for some other ASP", doesn't fit well to the ASP/SGP relationship IMHO, because I would expect RC to be defined per ASP (at least from protocol semantics perspective, otherwise how local configuration is entered to the system is something obviously implementation dependent) Thanks, Tolga > -----Original Message----- > From: Andrew Booth [mailto:abooth@pt.com] > Sent: Thursday, March 29, 2007 2:32 PM > To: Tolga Asveren > Cc: sigtran@ietf.org > Subject: Re: [Sigtran] correct Error code > > > Hi Tolga, > > It's a subtle point about the definitions. My personal views are > unchanged, but I think this argument is being addressed in the other > branch of this thread. > > My intended contribution just that the RFC appears to have some text > missing in one of the critical passages, that could perhaps be addressed > if there is ever another rev of M3UA. > > Andrew > > Tolga Asveren wrote: > > If RC is configured statically per ASP on SGP, I wouldn't think > it is wrong > > to say that it is invalid for that particular ASP. The peers > are ASPs and > > SGPs in that relationship. > > > > Thanks, > > Tolga > > > > > >> -----Original Message----- > >> From: Andrew Booth [mailto:abooth@pt.com] > >> Sent: Thursday, March 29, 2007 8:55 AM > >> To: Aditya; sigtran@ietf.org > >> Subject: Re: [Sigtran] correct Error code > >> > >> > >> Hi, > >> > >> I agree with Brian. The RC is not invalid, the SGP is just > refusing the > >> ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. > >> > >> As an aside, I think the text of the pertinent paragraph is missing > >> something. The meaning is fairly clear, but it should probably read: > >> > >> If for any local reason the SGP will not act on the ASP ACTIVE request > >> (e.g., management lockout) the SGP responds to an ASP Active message > >> with an Error message with reason "Refused Management Blocking". > >> > >> Andrew > >> > >> Brian F. G. Bidulock wrote: > >> > >>> Aditya, > >>> > >>> The RC is not invalid: the ASP is merely not permitted to > >>> > >> activate for it. > >> > >>> In this case it is management blocked. The peer should be welcome to > >>> retry, because at some point in the future it might be > >>> > >> permitted to activate > >> > >>> for the AS (e.g. the permission might have only been revoked > >>> > >> temporarily). > >> > >>> Sending "Invalid Routing Context" would make the peer believe that the > >>> corresponding RK is not provisioned (which it is) and might > result in a > >>> dynamic registration attempt (which is inappropriate). > >>> > >>> Besides, if "Invalid Routing Context" is returned, it violates > >>> > >> the MUST in > >> > >>> this passage: > >>> > >>> > >>> > >>>> - If the RC parameter is included in the ASP Active > >>>> > >> message and the > >> > >>>> corresponding RK has been previously defined (by either static > >>>> configuration or dynamic registration), the peer node > MUST respond > >>>> with an ASP Active Ack message. If for any local reason (e.g., > >>>> management lockout) the SGP responds to an ASP Active > message with > >>>> an Error message with reason "Refused Management Blocking". > >>>> > >>>> > >>> --brian > >>> > >>> Aditya wrote: (Thu, 29 Mar > >>> > >> 2007 05:53:59) > >> > >>>> Brian, > >>>> RFC 4666 mentions Invalid Routing Context to be sent if a > >>>> > >> message is > >> > >>>> received from a peer with an invalid(unconfigured) > >>>> > >> Routing Context > >> > >>>> value. Your analysis makes me think that only unconfigured > >>>> > >> RC is to be > >> > >>>> treated as Invalid. Isnt the RC invalid in the > >>>> > >> example mentioned > >> > >>>> below. > >>>> I may be wrong but sending ERR management Locked message > >>>> > >> somehow does > >> > >>>> not inform the peer that there is something wrong at its > >>>> > >> end. IMHO, > >> > >>>> "Invalid Routing Context" seems like an appropriate > >>>> > >> message, since the > >> > >>>> RC is INVALID in this case. The RC being configured does > >>>> > >> not take away > >> > >>>> from the fact that it is invalid. > >>>> Does RFC 4666 state anywhere that only unconfigured > >>>> > >> RC's are to be > >> > >>>> treated as Invalid? I mean, does it define Invalid RC in > any sense. > >>>> Aditya > >>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> Sigtran mailing list > >> Sigtran@ietf.org > >> https://www1.ietf.org/mailman/listinfo/sigtran > >> > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Thu Mar 29 16:33:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1Ir-0007At-Ps; Thu, 29 Mar 2007 16:33:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1Iq-00079D-CU for sigtran@ietf.org; Thu, 29 Mar 2007 16:33:00 -0400 Received: from audl951.usa.alcatel.com ([143.209.238.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX1Io-0005Aj-UM for sigtran@ietf.org; Thu, 29 Mar 2007 16:33:00 -0400 Received: from ssd.usa.alcatel.com (spdmail-qfe1.ssd.usa.alcatel.com [172.22.222.60]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id l2TKWwNU011191 for ; Thu, 29 Mar 2007 14:32:58 -0600 Received: from sun1588.ssd.usa.alcatel.com (sun1588.ssd.usa.alcatel.com [143.209.88.189]) by ssd.usa.alcatel.com (8.12.8/8.12.8) with ESMTP id l2TKWnRg013255 for ; Thu, 29 Mar 2007 14:32:50 -0600 (CST) Date: Thu, 29 Mar 2007 15:32:49 -0500 (CDT) From: "Samuel Dur D. Jeyaseelan" To: sigtran@ietf.org Subject: RE: [Sigtran] correct Error code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org according to your diagram, can u explain the one-to-one relationship between RC and RK ? --Samuel Alcatel USA, Inc. Internet: @ssd.usa.alcatel.com 1000 Coit Road, Plano, Texas 75075 ******* The opinions expressed are not those of Alcatel USA, Inc. ******* On Thu, 29 Mar 2007, Tolga Asveren wrote: > Hi Andrew, > > I don't think it is addressed :-). The point I tried to make was, if RC is > configured per ASP, considering RC values for other ASPs as the the "same" > RC doesn't sound correct. For example: > > +-------+ +-------+ > | ASP1 | | ASP2 | > +------++ ++------+ > | | > | | > | | > | | > | | > ++-----++ > | SGP | > +-------+ > Configuration for ASP1: > RC1: DPC=1-1-1, RC=1 > > Configuration for ASP2: > RC2: DPC=2-2-2 RC=1 > > RC1 and RC2 are using the same "RC" value but they are not referring to the > same RK. Basically, the concept of "RC being defined for some other ASP", > doesn't fit well to the ASP/SGP relationship IMHO, because I would expect RC > to be defined per ASP (at least from protocol semantics perspective, > otherwise how local configuration is entered to the system is something > obviously implementation dependent) > > > Thanks, > Tolga > > > > > -----Original Message----- > > From: Andrew Booth [mailto:abooth@pt.com] > > Sent: Thursday, March 29, 2007 2:32 PM > > To: Tolga Asveren > > Cc: sigtran@ietf.org > > Subject: Re: [Sigtran] correct Error code > > > > > > Hi Tolga, > > > > It's a subtle point about the definitions. My personal views are > > unchanged, but I think this argument is being addressed in the other > > branch of this thread. > > > > My intended contribution just that the RFC appears to have some text > > missing in one of the critical passages, that could perhaps be addressed > > if there is ever another rev of M3UA. > > > > Andrew > > > > Tolga Asveren wrote: > > > If RC is configured statically per ASP on SGP, I wouldn't think > > it is wrong > > > to say that it is invalid for that particular ASP. The peers > > are ASPs and > > > SGPs in that relationship. > > > > > > Thanks, > > > Tolga > > > > > > > > >> -----Original Message----- > > >> From: Andrew Booth [mailto:abooth@pt.com] > > >> Sent: Thursday, March 29, 2007 8:55 AM > > >> To: Aditya; sigtran@ietf.org > > >> Subject: Re: [Sigtran] correct Error code > > >> > > >> > > >> Hi, > > >> > > >> I agree with Brian. The RC is not invalid, the SGP is just > > refusing the > > >> ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. > > >> > > >> As an aside, I think the text of the pertinent paragraph is missing > > >> something. The meaning is fairly clear, but it should probably read: > > >> > > >> If for any local reason the SGP will not act on the ASP ACTIVE request > > >> (e.g., management lockout) the SGP responds to an ASP Active message > > >> with an Error message with reason "Refused Management Blocking". > > >> > > >> Andrew > > >> > > >> Brian F. G. Bidulock wrote: > > >> > > >>> Aditya, > > >>> > > >>> The RC is not invalid: the ASP is merely not permitted to > > >>> > > >> activate for it. > > >> > > >>> In this case it is management blocked. The peer should be welcome to > > >>> retry, because at some point in the future it might be > > >>> > > >> permitted to activate > > >> > > >>> for the AS (e.g. the permission might have only been revoked > > >>> > > >> temporarily). > > >> > > >>> Sending "Invalid Routing Context" would make the peer believe that the > > >>> corresponding RK is not provisioned (which it is) and might > > result in a > > >>> dynamic registration attempt (which is inappropriate). > > >>> > > >>> Besides, if "Invalid Routing Context" is returned, it violates > > >>> > > >> the MUST in > > >> > > >>> this passage: > > >>> > > >>> > > >>> > > >>>> - If the RC parameter is included in the ASP Active > > >>>> > > >> message and the > > >> > > >>>> corresponding RK has been previously defined (by either static > > >>>> configuration or dynamic registration), the peer node > > MUST respond > > >>>> with an ASP Active Ack message. If for any local reason (e.g., > > >>>> management lockout) the SGP responds to an ASP Active > > message with > > >>>> an Error message with reason "Refused Management Blocking". > > >>>> > > >>>> > > >>> --brian > > >>> > > >>> Aditya wrote: (Thu, 29 Mar > > >>> > > >> 2007 05:53:59) > > >> > > >>>> Brian, > > >>>> RFC 4666 mentions Invalid Routing Context to be sent if a > > >>>> > > >> message is > > >> > > >>>> received from a peer with an invalid(unconfigured) > > >>>> > > >> Routing Context > > >> > > >>>> value. Your analysis makes me think that only unconfigured > > >>>> > > >> RC is to be > > >> > > >>>> treated as Invalid. Isnt the RC invalid in the > > >>>> > > >> example mentioned > > >> > > >>>> below. > > >>>> I may be wrong but sending ERR management Locked message > > >>>> > > >> somehow does > > >> > > >>>> not inform the peer that there is something wrong at its > > >>>> > > >> end. IMHO, > > >> > > >>>> "Invalid Routing Context" seems like an appropriate > > >>>> > > >> message, since the > > >> > > >>>> RC is INVALID in this case. The RC being configured does > > >>>> > > >> not take away > > >> > > >>>> from the fact that it is invalid. > > >>>> Does RFC 4666 state anywhere that only unconfigured > > >>>> > > >> RC's are to be > > >> > > >>>> treated as Invalid? I mean, does it define Invalid RC in > > any sense. > > >>>> Aditya > > >>>> > > >>>> > > >>> > > >>> > > >> _______________________________________________ > > >> Sigtran mailing list > > >> Sigtran@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/sigtran > > >> > > > > > > > > > _______________________________________________ > > > Sigtran mailing list > > > Sigtran@ietf.org > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran > _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From sigtran-bounces@ietf.org Fri Mar 30 09:17:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGyb-0004EM-Hm; Fri, 30 Mar 2007 09:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXGyb-0004DJ-1U for sigtran@ietf.org; Fri, 30 Mar 2007 09:17:09 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXGyY-0002s7-IB for sigtran@ietf.org; Fri, 30 Mar 2007 09:17:09 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D9792B5800 for ; Fri, 30 Mar 2007 08:17:06 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id l2UDH5tf012071 for ; Fri, 30 Mar 2007 09:17:05 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Sigtran] correct Error code Date: Fri, 30 Mar 2007 08:11:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sigtran-bounces@ietf.org Sure. RC is just an agreement on a "name" for a specific routing key between a SGP and ASP. For messages coming from SS7 side, SGP still does the RK analysis, selects a suitable ASP and uses the corresponding RC value for that particular ASP/RK pair. I don't think protocol semantics require RC to be unique among all peers. This doesn't create any ambiguity. For example the use of "empty" name, i.e. not using a RC in messages if only a single RK is used between ASP and SGP, gives a per ASP (or per SGP, depending on whichever side one is looking from) meaning to "no RC". An SGP can send messages with no RC to two different ASPs (given that traffic to each particular ASP belongs to a single RK), referring to different AS. One could go with the globally unique RC approach, there is nothing wrong with it. For certain configurations, it could be quite inconvenient from provisioning point of view though. Consider the following case: +--------+ +--------+ | ASP1 | | ASP2 | +------+-+ ++------++ | | | | | | ++------++ +-+------+ | SG1 | | SG2 | +--------+ +--------+ For simplicity I draw SGs as single boxes, but they can consist of multiple SGPs, similarly each ASP can have multiple replicas. Each ASP and SG in the diagram is controlled by another organization, SGs by SS7 connectivity providers and ASPs by operators of application servers/VoIP gateways. Now, if each box interpretes RC to be unique among all peers it is conneced to, RC namespace needs to be administrated by some entity. For example, ASP1 and SG1 use RC=1 for RK:DPC=1-1-1. ASP2 can't use RC=1 for any of its RKs, even not for the ones it defines only for SG2 (if it wants to keep RC unique among all of its peers). This really would be a mess from provisiong point of view (imagine n number of ASPs and m number of SGs controlled by different organizations) Thanks, Tolga > -----Original Message----- > From: Samuel Dur D. Jeyaseelan [mailto:sjeyasee@ssd.usa.alcatel.com] > Sent: Thursday, March 29, 2007 3:33 PM > To: sigtran@ietf.org > Subject: RE: [Sigtran] correct Error code > > > according to your diagram, can u explain the one-to-one relationship > between RC and RK ? > > --Samuel > > Alcatel USA, Inc. Internet: > @ssd.usa.alcatel.com > 1000 Coit Road, Plano, Texas 75075 > ******* The opinions expressed are not those of Alcatel USA, > Inc. ******* > > On Thu, 29 Mar 2007, Tolga Asveren wrote: > > > Hi Andrew, > > > > I don't think it is addressed :-). The point I tried to make > was, if RC is > > configured per ASP, considering RC values for other ASPs as the > the "same" > > RC doesn't sound correct. For example: > > > > +-------+ +-------+ > > | ASP1 | | ASP2 | > > +------++ ++------+ > > | | > > | | > > | | > > | | > > | | > > ++-----++ > > | SGP | > > +-------+ > > Configuration for ASP1: > > RC1: DPC=1-1-1, RC=1 > > > > Configuration for ASP2: > > RC2: DPC=2-2-2 RC=1 > > > > RC1 and RC2 are using the same "RC" value but they are not > referring to the > > same RK. Basically, the concept of "RC being defined for some > other ASP", > > doesn't fit well to the ASP/SGP relationship IMHO, because I > would expect RC > > to be defined per ASP (at least from protocol semantics perspective, > > otherwise how local configuration is entered to the system is something > > obviously implementation dependent) > > > > > > Thanks, > > Tolga > > > > > > > > > -----Original Message----- > > > From: Andrew Booth [mailto:abooth@pt.com] > > > Sent: Thursday, March 29, 2007 2:32 PM > > > To: Tolga Asveren > > > Cc: sigtran@ietf.org > > > Subject: Re: [Sigtran] correct Error code > > > > > > > > > Hi Tolga, > > > > > > It's a subtle point about the definitions. My personal views are > > > unchanged, but I think this argument is being addressed in the other > > > branch of this thread. > > > > > > My intended contribution just that the RFC appears to have some text > > > missing in one of the critical passages, that could perhaps > be addressed > > > if there is ever another rev of M3UA. > > > > > > Andrew > > > > > > Tolga Asveren wrote: > > > > If RC is configured statically per ASP on SGP, I wouldn't think > > > it is wrong > > > > to say that it is invalid for that particular ASP. The peers > > > are ASPs and > > > > SGPs in that relationship. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > >> -----Original Message----- > > > >> From: Andrew Booth [mailto:abooth@pt.com] > > > >> Sent: Thursday, March 29, 2007 8:55 AM > > > >> To: Aditya; sigtran@ietf.org > > > >> Subject: Re: [Sigtran] correct Error code > > > >> > > > >> > > > >> Hi, > > > >> > > > >> I agree with Brian. The RC is not invalid, the SGP is just > > > refusing the > > > >> ASP ACTIVE. Hence "Refused Management Blocking" is appropriate. > > > >> > > > >> As an aside, I think the text of the pertinent paragraph is missing > > > >> something. The meaning is fairly clear, but it should > probably read: > > > >> > > > >> If for any local reason the SGP will not act on the ASP > ACTIVE request > > > >> (e.g., management lockout) the SGP responds to an ASP > Active message > > > >> with an Error message with reason "Refused Management Blocking". > > > >> > > > >> Andrew > > > >> > > > >> Brian F. G. Bidulock wrote: > > > >> > > > >>> Aditya, > > > >>> > > > >>> The RC is not invalid: the ASP is merely not permitted to > > > >>> > > > >> activate for it. > > > >> > > > >>> In this case it is management blocked. The peer should > be welcome to > > > >>> retry, because at some point in the future it might be > > > >>> > > > >> permitted to activate > > > >> > > > >>> for the AS (e.g. the permission might have only been revoked > > > >>> > > > >> temporarily). > > > >> > > > >>> Sending "Invalid Routing Context" would make the peer > believe that the > > > >>> corresponding RK is not provisioned (which it is) and might > > > result in a > > > >>> dynamic registration attempt (which is inappropriate). > > > >>> > > > >>> Besides, if "Invalid Routing Context" is returned, it violates > > > >>> > > > >> the MUST in > > > >> > > > >>> this passage: > > > >>> > > > >>> > > > >>> > > > >>>> - If the RC parameter is included in the ASP Active > > > >>>> > > > >> message and the > > > >> > > > >>>> corresponding RK has been previously defined (by > either static > > > >>>> configuration or dynamic registration), the peer node > > > MUST respond > > > >>>> with an ASP Active Ack message. If for any local > reason (e.g., > > > >>>> management lockout) the SGP responds to an ASP Active > > > message with > > > >>>> an Error message with reason "Refused Management Blocking". > > > >>>> > > > >>>> > > > >>> --brian > > > >>> > > > >>> Aditya wrote: (Thu, 29 Mar > > > >>> > > > >> 2007 05:53:59) > > > >> > > > >>>> Brian, > > > >>>> RFC 4666 mentions Invalid Routing Context to be sent if a > > > >>>> > > > >> message is > > > >> > > > >>>> received from a peer with an invalid(unconfigured) > > > >>>> > > > >> Routing Context > > > >> > > > >>>> value. Your analysis makes me think that only unconfigured > > > >>>> > > > >> RC is to be > > > >> > > > >>>> treated as Invalid. Isnt the RC invalid in the > > > >>>> > > > >> example mentioned > > > >> > > > >>>> below. > > > >>>> I may be wrong but sending ERR management Locked message > > > >>>> > > > >> somehow does > > > >> > > > >>>> not inform the peer that there is something wrong at its > > > >>>> > > > >> end. IMHO, > > > >> > > > >>>> "Invalid Routing Context" seems like an appropriate > > > >>>> > > > >> message, since the > > > >> > > > >>>> RC is INVALID in this case. The RC being configured does > > > >>>> > > > >> not take away > > > >> > > > >>>> from the fact that it is invalid. > > > >>>> Does RFC 4666 state anywhere that only unconfigured > > > >>>> > > > >> RC's are to be > > > >> > > > >>>> treated as Invalid? I mean, does it define Invalid RC in > > > any sense. > > > >>>> Aditya > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> Sigtran mailing list > > > >> Sigtran@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/sigtran > > > >> > > > > > > > > > > > > _______________________________________________ > > > > Sigtran mailing list > > > > Sigtran@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > > > > > > _______________________________________________ > > Sigtran mailing list > > Sigtran@ietf.org > > https://www1.ietf.org/mailman/listinfo/sigtran > > > > > _______________________________________________ > Sigtran mailing list > Sigtran@ietf.org > https://www1.ietf.org/mailman/listinfo/sigtran _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www1.ietf.org/mailman/listinfo/sigtran From hika_ruru4568@yahoo.ca Fri Mar 30 19:57:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXQyP-0007KH-Eo for SIGTRAN-ARCHIVE@LISTS.IETF.ORG; Fri, 30 Mar 2007 19:57:37 -0400 Received: from [222.170.89.82] (helo=allabout.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXQyJ-0006q6-Kx for SIGTRAN-ARCHIVE@LISTS.IETF.ORG; Fri, 30 Mar 2007 19:57:36 -0400 Received: from kqrj1 (unknown [118.172.29.238]) by smtp22 (Coremail) with SMTP id JcG5u5tqoFBEP8EH.1 for ; Wed, 24 Mar 2004 09:35:41 +0800 (CST) X-Originating-IP: [118.172.29.238] X-Spam-Score: 4.1 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db - From: To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478